* Case Number: a20141024.1 * Status: execution * Claimant: Bruno * Respondent: CAcert * initial Case Manager: EvaStöwe * Case Manager: MartinGummi * Arbitrator: EvaStöwe * Date of arbitration start: 2014-12-07 * Date of ruling: 2015-04-13 * Case closed: 201Y-MM-DD * Complaint: terminate assurer account Bruno * Relief: terminate assurer account Bruno Before: Arbitrator EvaStöwe (A), Respondent: CAcert (R), Claimant: Bruno (C), Case: a20141024.1 == History Log == . 2014-10-24 (issue.c.o): case [s20141007.98] . 2014-11-10 (iCM): added to wiki, request for CM / A . 2014-11-10 (iCM): notified C about case . 2014-12-07 (A): I'll take care of this case together with CM . 2014-12-07 (A): init mail to C . 2014-12-07 (A): requests more account details from support . 2014-12-07 (Support): provides requested account details . 2015-01-25 (A): repeated mail to C . 2015-03-30 ruling in [[Arbitrations/a20141231.1|a20141231.1]] was given . 2015-03-31 (A): presented proposed process to a Support team member, who saw no issues . 2015-04-07 (A): repeated this with a slightly updated version of the process . 2015-04-08 (A): informed the internal Auditor about the intention to install the new process . 2015-04-13 (A): ruling send to C, Support, CM . 2015-04-13 (A): informs board and Arbitration team about new precedents ruling == complete communication history of this case (partly anonymised) == Because there were a lot of activities steered up because of some decisions in this case, a complete history of the communication as documented in the private part of this case is published. The DRP states, that the proceedings are ordiarily private. But this case seems to be of public interest. The reasoning behind this decision is: * Nearly all people who were involved in this case were acting in an official role they have. * We claim to be transparent in our actions. This in general covers actions done in an official roles. * There was public interest for this case. Because of the the Arbitrator of this case has decided to make the communication of this case (the collection within the private part) public, in a partial anonymised version. [[Arbitrations/a20141024.1/statements|communication of a20151024.1]] == Private Part == * '''Link to Arbitration case [[Arbitrations/priv/a20141024.1|a20141024.1 (Private Part)]], Access for (CM) + (A) only''' ## ==> INCLUDE SECTION BOT <> ## <== INCLUDE SECTION EOT ==== EOT Private Part ==== == original Dispute == {{{ Hello, please terminate my account and send me a confirmation of termination. Thank you very much }}} == Discovery == * The claimant did request to get the account deleted. He did not respond to the request to hand the CAP forms of the given assurances over to the Arbitrator. * With regard to the ruling given in [[Arbitrations/a20141231.1|a20141231.1]] the account can be closed, even as the claimant did not respond. Since the latest changes of the [[https://www.cacert.org/policy/CAcertCommunityAgreement.html|CAcert Community Agreement]] (CCA) the termination of accounts does not have to be handled by an Arbitrator if a process for the termination of accounts is defined by an Arbitrator in an Arbitration case. Support is able to handle the termination of accounts when no CAP forms have to be handed over, or any other special action has to be done, comparable cases do not need to be handled by Arbitration. Since the ruling given in a20141231.1 it is clear that delete account cases for assurer accounts do not require either the revocation of assurances or a handover of CAP forms, which both would have needed the direct authority of an Arbitrator. Cases that are comparable to this one could be handled by Support, if an according process is defined in a precedents ruling. This should be done in this case. As it is sensible to have only one process for all delete account cases the process defined here should also replace any previous delete account processes definitions by Arbitration, including [[Arbitrations/a20111128.3|a20111128.3]] and [[Arbitrations/a20140713.1|a20140713.1]]. This is also sensible as some elements defined in a20111128.3 are not needed anymore since the latest changes of the CCA (and some previous software changes). === Process Definition === 1. The support case has to be marked as a delete-account request. 2. The Support-Engineer checks the users account for * certificates that are valid * certificates that are not expired/revoked for 3 months * assurances given within last 7 years * assurances given over 7 years ago 3. The Support-Engineer writes a mail to the user to explain the process and to make sure that the request to get the account delete request is genuine. The mail should contain the following elements (based on the results of Step 2) in a sensible order: * information when delete request was received * request to respond if the deletion of the account is not the wish of the user, with the information that else the account will be closed * optional: option to confirm delete request to fasten the process * deadline of about 2-3 weeks for the response * short explanation of the delete process * information that some risks, liabilities and obligations for the time of the membership, may continue even when the membership has ended * optional: information of alternative activities for common issues like lost passwords * optional: proposal to block the account * if this is added the wording has to be clear that it is optional and no requirement for the closure of the account * if valid certificates were found: * information that they will be revoked after the deadline has passed, if the user does not intervene * if certificates were found that are not expired/revoked for 3 months: * information that account has to be kept open until 3 months after the last certificate has expired/was revoked * date when this will presumably be the case * if any given assurances were found: * reminder that CAP forms have to be kept safely for 7 years after the assurance and that they have to be safely destroyed, afterwards * request to confirm that this has be done and/or will be done for remaining CAP forms * if given assurances within the last 7 years were found: * information that if the assurances given by the assurer are questioned (for whatever reason) they have to be revoked, if CAcert cannot reach the CAP forms * favoured option by CAcert that the user hands over the CAP forms to another assurer defined by an Arbitrator * information that the user may name such an assurer * information that if CAP forms have to change hands, the case will have to be handled by Arbitration * statement that the user may change any of the above decision until the account is deleted 4. Wait until either the user confirms the deletion request or the deadline expires 5. If the user was an assurer and did not confirm the point about the CAP forms * step 3 and 4 should be repeated 2 more times by the Support-Engineer * not all points from step 3 have to be repeated explicitely in the new mails, if it can be assumed that the member is informed about them [for example by a quote] * in the last repetition the request for confirmation should be re-worded so that getting no answer can be interpreted as a confirmation 6. If the user is an assurer and has decided to hand over the CAP forms, the case has to be moved to Arbitration - the automatic Support activity ends in this case 7. The Support-Engineer revokes any valid certificates 8. If the user has agreed or requested to an account block the Support-Engineer should block the account 9. Wait until all certificates are revoked or expired for at least 3 month 10. Document the deletion of the account as described below as "Documentation" 11. Close the account as described below at "Account closure" 12. immediately inform the user about the successful account closure, stating the date of the closure of the account as the CCA termination date for the user. General: * If the user decides to keep the account the process should be stopped. * If the user changes the mind about the blocking of the account before the account is finally deleted, the Support-Engineer has to set or reset the block accordingly. In the context of the process defined here, an account may only be blocked with the explicit agreement of the affected user. This does not affect account blocks that are done for other reasons. If a sensible way would be found so that it could be easily checked if the user who requests termination of the account is involved in an arbitration case, so that the membership should not be ended before the case is finished according, this should be checked as step 0. In the case that the Support-Engineer knows that the user is involed in such an Arbitration case the Arbitrator or (i)CM of that case should be addressed before the process of closing the account is continued, if no Arbitrator or CM could be identified or responds, the DRO should be addressed instead. The user should be informed about this. One possible way to proceed would be to allow the closure of the account without terminating the membership. Currently there is no way for Support-Engineer to know for sure that a user is not involved in an arbitration case, so this check cannot be done in a clearly defined manner. ==== Documentation ==== Document the delete account issue by adding it to the new [[Arbitrations/Audit/a20141024.1|table]] at the end of the Audit Section linked into the precedent case a20111128.3 with: * Support ticket number * Arbitration number + consecutive number => a20141024.1.# * CCA termination date (this is the SE's execution date) * "A" if the user is an assurer with all given assurances older than 7 years * "AC" if the user is an assurer with given assurances that are not 7 years old and were the case was not handled by Arbitration * The table should explain the usage of "A" and "AC". ## Edit from (A) at 2016-06-10, formerly: Document the delete account issue by adding it to the [[Arbitrations/Audit/a20111128.3|table]] at the end of the Audit Section linked into the precedent case a20111128.3 with: ## Edit from (A) at 2016-06-10, formerly: * Arbitration number + consecutive number => a20111128.3.# ==== Account closure ==== The account should be closed by the Support-Engineer using the delete account option in the Support Console. This is an automatic form of the process defined in the context of a20111128.3 and described [[Arbitrations/Training/Lesson20/DeleteAccountProcSEv3|here]]. (Note: If the content of the page linked here is moved, the link should be updated, accordingly!) ==== Note about step 5 ==== The Support Engineer who looked over the above process was not happy with step 5, as this will allow assurer to leave without an explicite statement that they will keep the CAP forms save and destroy them after the 7 years are over. The reasons for this solution are: * There is no sensible alternative. * People who ask for the deletion of an account possibly do not read a direct response to that request, because they think that they already know about the contend of such a mail. But if one gets a correct looking mail with a support case number from the same organisation later, chances are that they would read those mails, as those mails are unexpected. * The first impulse from the Support-Engineer (and others) is to at least revoke the assurances. * But this neither needed nor helpful. * The statement is requested to protect the rights of the assurer. To revoke assurances just because those rights may be violated is definitely hurting the assurer (and probably more than if a CAP form is not destroyed, directly). * the ruling of a20141231.1 stated that it is not in the interest of the community and against the AP if CAP forms are destroyed just because we do not know about their status, the according arguments are also valid, here. * If the users do not (want) to respond, they will not do so, whatever we do. * To spend either more support time, or even start an Arbitration case about this to spend even more Arbitration time on this, is disproportional. * If going through step 3 and 4 up to three times, we have tried with a reasonable effort to address the issue. * The assurer is already bound to act as the statment requests. This is not changed if the assurer answers, or not. In theory the statement is not really needed, but it is valuable to have it. ==== additional Notice for Support ==== The process defined here will be a process directly under the CAcert Community Agreement [[https://www.cacert.org/policy/CAcertCommunityAgreement.html|(CCA)]] based on the ruling in this case. No adaption of an Arbitration init mail is needed, as it was done previously, before the last CCA changes, to place it make it into a short version of an Arbitration case. ==== current case ==== With the above process the account could be handled by support. The short investigation at the beginning of the case showed no unusual things regarding the claimant or his account. == Edits to process == . 2016-06-10 (A): Edit to documentation description == Ruling == === original Ruling === The delete account process for assurer and non-assurer accounts should be changed as described in the process definition part of the discovery of this case file. This process replaces all delete account processes defined in previous precedents cases for delete account cases that are handled by Support, including [[Arbitrations/a20111128.3|a20111128.3]] and [[Arbitrations/a20140713.1|a20140713.1]]. The main reason for the new process are recent changes of the [[https://www.cacert.org/policy/CAcertCommunityAgreement.html|CAcert Community Agreement]] and the ruling given in [[Arbitrations/a20141231.1|a20141231.1]]. Support should take care that all Support-Engineers are aware of the new process. It would be appreciated if the relevant process descriptions in the support area would be updated, accordingly. If issues arise with the process within three months after the ruling, the process may be updated by the Arbitrator of this case, or the Case Manager or a Support-Engineer if they have the confirmation of the Arbitrator to do so, as long as the core elements stay the same. Substantial changes should be noted in the case log. The account of the claimant should be closed as requested by the claimant. The new process should be used. Even as some steps were already done by Arbitration, Support should start with step 1. Frankenthal, 2015-04-13 === Follow-up Ruling === As the CAcert Community Agreement was not correctly terminated by the execution of the original ruling that I gave in this case I hereby terminate the Agreement with the claimant of the case. The termination date will be 2015-04-16, as the claimant was told it to be in a previous mail from support. Cologne, 20150-05-03 === Order given to prevent further miss-executions === {{{ Dear SEs, dear board, I regret to have to do this, but in this case it looks like the only sensible thing to do for the moment. As the Arbitrator of a20141024.1 I have to ask you to do the following things. 1. Please remove the access rights from [Support Engineer who tried to execte the ruling] to - the Support console - the OTRS for the time being. This is not meant to be permanent. But I fear it is necessary to ensure that support activity in critical areas are done correctly, especially that the ruling of a20141024.1 is executed correctly. Regrettably, I had to witness that [name of SE] seriously failed to execute the Arbitration ruling of this case. It was not the first time, that rulings were not executed by him exactly, however at other times it was less dramatic. Also it is clear that he did some other activities without the required authorisation, recently, as well, like: - looking up a members account without either the authorisation from the member nor the authorisation from Arbitration - posting information from the account on a public mailing list, also without any authorisation. While those activities are not handled in this case, they influence my weighting of the situation. Currently I have to fear, that it cannot be ensured that support activity (especially those for delete account cases) is done with the authorisation required by SP, but even worse that the CCA is terminated correctly in those cases as defined in the CCA, if [name of SE] is handling the according cases. 2. Please also: Organise a re-training of [name of SE] about - required authorisations to do something as a Support Engineer starting with the SP - how to handle delete account cases with special respect to the ruling in a20141024.1 - how to handle Arbitration rulings, especially if some points are unexpected or unclear. 3. Please document the training. As soon as either board or the Arbitrator of this case (or a follow up case for this point) is convinced based on the documentation, that the retraining was successfully done, the access to the Support console and the OTRS should be given back, as long as neither board nor the support team lead decide differently. I hope this will only take some days. I have consulted the President of CAcert Inc. before writing this. }}} This order was given at 2015-04-19 in Solingen === Follow Up Ruling II === I hereby come to the following follow up ruling: 1. Dirk Astrath and Guillaume Romangy should be added temporarily to the Support Engineer team. Dirk should gain access to the support console. Guillaume should gain access to the Support OTRS-queues. Both of them should get any other access necessary for support work. Together they should help out within the Support team. 2. Both should take special care that the work of support is done correctly and should especially help each other in this regard. When establishing necessary channels of communication they should consider how to secure the privacy of the affected members. 3. Dirk and Guillaume are asked to make themselves familiar with the work of an support engineer. They should undergo each available training in this regard. 4. Board and any support engineer are asked to consider to initiate an ABC for Guillaume by filing an according dispute. If such a dispute is filed, Arbitration should handle it with priority as long as Guillaume works as temporary Support Engineer. 5. Any support engineer is asked to help the temporary Support Engineers to enable them to do the work, including any necessary training or information. 6. Dirk is suspended from active regular Software Assessor work. He may be active in emergency situations. (Situations where a necessary bug cannot be installed in an acceptable amount of time, without his review.) The above points are valid until at least two regular support engineers are active on a regular basis, or if revoked by the Arbitrator of this case or a follow up case. This ruling should be reviewed by the according Arbitrator, when at least one regular support engineer is found to be active on a regular basis. Any such activity should be reported to the according Arbitrator. The according Arbitrator should also consider a review if either Dirk or Guillaume, Support or board ask for it. Board is asked to aim to get two regular active Support Engineers working in the support area. This may include to get the temporary Support Engineers to be full flagged regular Support Engineers. -- Wien, 2015-09-07 The above is necessary because and based on the following: Security Policy[2] (SP) 9.1.2. first sentence gives the following requirement: "Each team should have a minimum of two members available at any time." Currently this does not seem to be the case for support. At the board meeting of 2015-09-06 board decided to ask the Arbitrator to get a temporary replacement added to fulfil the requirements for the team staffing. SP 9.1.3. "New team members need: * Recommendation by team leader * Arbitrated Background Check ("ABC") * Authorisation by Board" There seems to be no candidate who fulfils those requirements. Also at least two out of the current four support engineers have declared that they are not available for regular support work for the time being. Also time has shown that it takes much longer to get Werner through the requested re-training, than originally assumed by the Arbitrator, so he probably will not be able to do regular support work for an undefined amount of time. Approaches to hasten this, remain to be welcomed. SP 9.1.1 defines the roles and responsibilities at least for the context of staffing. It includes: "Arbitrator: conducts ABCs. Authorises exceptions to policy." As there is no way for board to ensure the minimum of active support engineers which is required by the SP by people who match the requirements of the SP, an exception to the SP requirements is required. Dirk has an ABC that was initiated for support work. Guillaume misses an ABC but - according to board - has done support work, previously. Board had proposed to give them access as granted by the Arbitrator to solve the situation. As board is the authority who normally has the responsibility to select and install Support Engineers, the voice of board should be relevant for the selection of team members. As Dirk has the required ABC and only Guillaume will not get access to the database, the critical access remains only available for persons with an ABC. The sabbatical for the Software Assessor role of Dirk is indicated because of SP 9.1.2 second sentence "Individuals should not be active in more than one team at any one time, but are expected to observe the other teams." However both roles are not exclusive. === Follow up ruling III === The following ruling should a) close the issues which arose via the execution b) withdraw the arbitration authority from managing support team as much as possible and approve prior decisions from board and others in that area d) emphasise the need to staff up the support team so that one can entrust this team with processes like the delete account process {{{ I hereby rule: 1. Dirk, board, support-TL and the Arbitrator did a lot of steps to enable Dirk to become a full-flagged support engineer. While all requirements from the Security Policy (SP)[2] 9.1 to join that team are visible, some of them were not done exactly as required or in the requested order. But as the intention is more important than the specific process, I hereby use the authority as Arbitrator to allow exceptions from process provided by SP 9.1.1. and rule that the derivations to process are minor and Dirk was installed as Support Engineer, successfully. 1.a. Board added an additional requirement for all support team members above those from SP in motion m20140713.1 [3]: All support engineers have to pass the privacy CATS. Dirk does not fulfil this requirement so far, as the privacy CATS is not productive, at the moment. He has one month to convince the Arbitrator of this case, that he fulfils the requirements of the privacy CATS. The result has to be noted in this case file. 2. The follow up ruling II in this case did not work out as planned because of multiple interferences and complications. By this all its provisions are cancelled. 3. If Guillaume shows interest, board may grant him the access he was allowed to have via follow up ruling II, if board coordinates this with the support team, without following a specific process. However in that case board should aim to get any missing elements covered as far and soon as possible. 4. Werner has resigned from support team. There is no direct need for a training any more and the topic should be dropped. Should he ever apply for a job under SP again, he has to convince an arbitrator (in a case) that he has performed the training as it was described in follow up ruling I before he may be allowed to do that job. 5. Marcus has resigned from support team. Prior to this he had at least once refused to follow simple orders of the Arbitrator and instead decided to do no further support activities for months. Should he ever apply for a job under SP again, he has to convince an arbitrator (in a case) that he will follow orders from any arbitrator and processes in the future. 6. The SP requires to have at least two active members for each critical team like support engineers. The current failure to keep the support team staffed as required by the SP and this already had lead to grave problems which may even have lead to a situation where security relevant mails were not read, and also delete account requests were not handled as requested which also may have lead to situations where members stop to care for their accounts or certificates which may lead to issues with those certificates. Combined with some of the issues seen in this case, this shows, that the provision of the SP to have at least two active team members in the critical teams is sensible and relevant. The availability of a team should not depend on one person only. If there is only one active team member there should be at least some oversight and possibility to step in in emergencies from at least one other person. 7. This ruling will only provide one active support engineer. Because of this board has to present a solution for said oversight as long as only one active support engineer is active. 7.a. A possible solution may be that the support-TL will take a look into the OTRS in regular intervals or when requested by Dirk. But board has the full authority to define any other solution they regard to be promising. 8. SP 9.1.3. requires an Arbitrated Background Check (ABC) for new members of the teams under SP like support engineers. A ruling given in a20140124.1 [4] forbids that ABCs are performed until the Arbitrator of that case provides a new process. However he did accept current ABCs. As those remain acceptable and there is a security need to perform ABCs the provision of the ruling of a20140124.1 have to step back if a team drops under the required amount of team members. Because of this an exception to the ruling in a20140124.1 is given so that up to 3 ABCs are allowed to be performed for candidates for the support team with the current process until a new process is provided. 8a. The same would be true for any other team in a comparable situation. Or if the support team drops below the required number of members, again. 9. Should CAcert not be successful to get to a situation where there are either two active support engineers or at least enough serious candidates for the job of support engineers within half a year after this ruling, the support team has to be closed down. While a situation with only 1 support engineer can be tolerated for some while even as it breaches the SP under the oversight of an arbitrator, there is a limit how long this is acceptable. If that situation cannot be solved in over 1,5 years with no perspective for improvement, it is likely that this limit is crossed. 10. If the Arbitrator of this case comes to the conclusion that there is some reason to believe that the situation is likely to improve after said half year, the Arbitrator may increase the grace time for closure accordingly on request of board. If during this time CAcert succeeds to get two active support engineers or serious candidates, support does not have to be closed down. 11. Because it is unknown how much the process defined in the original ruling was tested, the 3 months for adjustments to the process are reset by this follow ruling III and start again with this follow up ruling III. 12. Beside of the activities named in this ruling, no further actions are intended to be done in this arbitration case. It should be closed as soon as possible with the above provisions in mind. Eva Stöwe, 2016-05-27 ~~~~~ [1] https://wiki.cacert.org/Arbitrations/a20141024.1 [2] https://www.cacert.org/policy/SecurityPolicy.html [3] https://community.cacert.org/board/motions.php?motion=m20140713.1 [4] https://wiki.cacert.org/Arbitrations/a20140124.1 }}} == Execution == . 2015-04-13 (A): ruling send to C, Support, CM . 2015-04-16 (Support): response to ruling: "I disagree with your decision [...]. It is not well thought and therefore not applicable." . 2015-04-16 (A): some points should be clarified more in the process; could not find a point that would be blocking reason against the ruling . 2015-04-16 (Support): implies that the claimants account was already checked, so account was terminated, uses deprecated precedents case . 2015-04-16 (A): Informs Suppot about wrong execution, asks for explanation . 2015-04-16 (Support): stats that the Arbitrator is not able to give such rulings, does not believe anything the Arbitrator says, further discussion about block . 2015-04-16 (A): provides references, reasonings, informs about authorisation based on policies, explains decisions . 2015-04-16 (A tries to calls the acting Support-TL for clarification and to sort things out) . 2015-04-17 (Support): answers handling of the execution: ruling was not clear, guessed things, found it would not make sense to do the full process, thought to be doing the execution correctly . 2015-04-17 (A): explains ruling again, this part hardly could be written less obscure, if something was unclear the Arbitrator should be asked about the meaning, also the answer would have been obvious by checking the case file . 2015-04-17 (A short telephone call with acting Support-TL) sees a need to order a re-training with a support-block so far for acting supporter, acting Support-TL had had no time to look into the issue, and did not answer the phone for the next two days . 2015-04-19 (A): ordes re-traing for acting support team member, and block support access until it is done . 2015-04-19 (Support): explains his view of authorisations including "for a Support member there are no restrictions to view sensitive data" and stating that an Arbitrator does not have the right to give rulings to change the delete account processe- without referencing (or responding to references of) policies . 2015-04-20 (A): answers to last mail, explaining reasonings, and policies, giving references, will not answer same things, again . 2015-04-20 (vice president): filed [[Arbitrations/a20150420.1|a20150420.1]] - probably an appeal against this case/the order given at 2015-04-19 [dispute unknown to A of this case, when writing this log entry at 2015-05-03, accordig case file says: filing of dispute WIP] . 2015-04-20 (A): complains before board about new dispute, because it interferes with a running case . 2015-04-21 (Support): does not know about "PolG" or termination point in CCA, does not accept CCA 3.3, PolG do not know what they do, Support should look into accounts when people ask questions on public-support-list, the interpretation of the SP that Support needs an authorisation before handling cases is wrong, makes Arbitrator responsible for things the internal Auditor did . 2015-04-21 (President): acknowledgs that there was a lot of work preceding this ruling; the ruling has to be executed correctly, please see CCA; it was not done here; there were a lot further activities by the SE with comparable issues, so a re-training of was quite overdue, especially when this person handles most support cases and the acting support-tl was asked ot do it informally multiple times; the focus of the order from 2015-04-19 is the re-training, not the block, which also can be removed by board according to the order, if necessary; Arbitration is needed to check that support acts according to policies; Audit will nail us down if we allow people to continue to act against policies; an Arbitrato has to give according orders to fix issues, nobody should be excluded from this because of being extremly active; an Arbitrator mostly has reasons; if in doubt one should ask and talk first, "don't place the next Arbitration case again by showing that CAcert (furthermore CAcert board member in this case) does not accept a ruling done by Arbitration" . 2015-04-21 (A): again asks Support team to block access to support-tools for acting supporter and to do the re-training . 2015-04-21 (Support): provides text proposal for delete account case(s) . 2015-04-21 (Support): executed support block . 2015-04-22 (A): thanks for support block, asks for ASAP re-training to remove block again . 2015-04-22 (A): addresses text proposal (with two mails) . 2015-04-23 (A): learned from reliable source (not support) that there may be an issue with support being able to act if the SE is blocked because of un-availability of another SE for some time; some proposals how the block could be adjust to address the issue, if re-training could not successfully be finished, previousy; request to support to tell which sulution would be prefered; also: it seems that support is planning to do a way more for the re-training than asked in the order . 2015-04-26 (A): A: repeats request to support to inform about possible issues with the support block; wonders if there actually is an issue . 2015-04-26 (Support) reports about executed re-training, with partial documentation . 2015-04-27 (A): thanks support for approach, but some points are neither not sufficient or not sufficently documented; repeats request to answer last mail; asks board members to indicate if re-training would probably be accepted by board . 2015-04-28 (a board member): informs A that at least two board members will consult on this topic within next 48h . 2015-04-28 (A): thanks the board member for that approach . 2015-04-28 (A): relayed board members information ot rest of board and support . 2015-05-03 (A): additional answers to mail proposal . 2015-05-03 (A): follow-up ruling send to C, CM . 2015-05-06 (A): remainder to Support to inform about further re-trainings, if there is no respons regarding how to solve staff-shortage, there is probably no issue in this regard; question to board if they want to address the re-training, as they could let it pass as well . 2015-05-11 (President): board does not regard the re-training as successfull, other parts are missing or not documented, with detailes to some points; suggests telefon conference between president, A and the trainer . 2015-05-11 (A): forwards answer from board to Support and explicitely to Support-TL, trainer and trainee, and CM: asks board to correct the interpretation if it is wrong: "not happy with the result of the re-training and currently does not plan to give back the access based on it"; asks support to outline the further training which should be soon (also in the interest of support) . until 2015-05-27 (President): organises a telefon conference between him, A and trainer . 2015-05-27 (President): reminds A and trainer about telco that evening, trainer had warned that he may be late . 2015-05-27 (President, A): waiting in telco, trainer does not appear; eventually president calls trainer who answers that he is busy with his job and will provide a new date within the next day . 2015-05-31 (President): reports to board and A, trainer in CC: report of his tries to organise a conference; summary of events regarding the block of the SE and its removal; summaries that this shows him "that Support does not want to get the SE-block removed"; declares support to be blocking further solutions; regards filing of a20150420.1 "was started to do ARB-bashing" instead of working on a solution . 2015-06-09 (A): contacts CM to inform him about possible further activities if support does continue to not answer; CM responses as DRO (other of his roles) why he was not informed about anything and why he was not informed about the idea of such activities as the DRO previously and that any harsh decisions have to be discussed within the arbitration mailing list and/or with the DRO, does not comment the idea . 2015-06-09 (A): forwards two recent mails that the CM had not got to CM; explains delay from about one week; declares/explaines that there is no need to discuss any arbitrator-decision within the arbitration team or with the DRO. There were a lot drastic decisions done by A or other Arbitrators that were not discussed there, either. . 2015-06-23 (A): asks trainer to provide president with new dates for a possible telefone confrence, during the software telco; trainer: agrees that progress is currently blocked by supprt; trainer promises to provide the president with possible dates within the next day . 2015-06-30 (President): forwards mail from trainer (28.06.) to A - trainer only answered after 5 days, because of computer issues for 3 days, wants also to have support-TL to be present - possible dates are in (during the previous software telco) declared vacation of president, the earliest 2 weeks later - president will not be able to make that days . 2015-06-30 (A): this should not wait two more weeks or more, it seems to be a real issue for support, also support (especially trainer) has had enough time to provide a sensible date and to answer the mails and questions from A - both was not done - A orders a conference within that week at a time selectable by support, where 1 support representant, A and one out of 3 board members should be persent, A should be informed about date ASAP - if this does not work there have to be consequences for support team members . 2015-07-03 (A): remainder / question about date of conference - remainder that if this does not work that there have to be consequences for support team members . 2015-08-22 (A) organised face-2-face meeting about re-training between A, president, trainer - trainer insinsted on an "neutral" observer "of his choice - because the trainer announced that he will leave the meeting after 10 minutes A accepted the observer, even as A had privacy concers, because the observer is allowed a lot of things as he happens to be the internal auditor) During the meeting the trainer stated that he regards the training to be finished, that he could not provide any more information without looking up his notes, this included a question why he had not time to answer for 3 monts, trainer promised to update the training report until 2015-08-30 (according to the notes of the observer); as time was short it was agreed to continue the meeting at the next day, trainer was asked for time restrictions on next day . 2015-08-23 (A) tried to initiate the continuation of the meeting from previous day, president was available, trainer refused to join as the observer of his choice had no time, at a time suggested by the trainer either A or president had no time, trainer insisted for that timeslot as he refused to have a meeting without "a neutral person of his choice"; A explained that there was no need for a neutral observer, especially as both A and the president have to be neutral; trainer announced that he does not respect A anymore, that he does not accept any authority of A in this case and announced that he would just leave directly so that a meeting would not be possible on eihter time (directly or later when the observer maybe had time), A reminded him that such a decisions would be a refusal of an arbitration request which would be against DRP and CCA which could lead to consequences including termination of roles like that of a support engineer; the trainer announce to leave anyway and to volunteering stop to work for support; the trainer then left the event . 2015-08-25 (A): asks observer of session with Trainer to provide his notes . 2015-08-28 (observer): explains why he could not send the notes so far; asks if next Tuesday would be enough . 2015-08-29 (A): tells observer that next tuesday would be fine . 2015-08-31 (secretary): asks A if she knows about the SE (trainer) who declared to do support work by the re-try of the meeting - board was informed about no activity on support side by a triage member . 2015-08-31 (A): probably there is nobody working in support; would have reported knowledge to board, if President had not asked to get some time to report to board, prior to A; explains shortly behavior of trainer at the event, that he had declared to stop working for support and that he probably was the last active SE at that time; reminds that there was a proposal to help out if support was short-manned because of block of one supporter; there was an approach to do an ABC to create candidates for support . 2015-09-02 (observer): sends his notes of the meeting . 2015-09-02 (A): thanks the observer of the meeting for his help . 2015-09-06 (A): informs board about events on FrOSCon (after a grace time so that board could be informed by the president), the notices of the observer were included (as well as an English transcript) reminds bord of the issue to get the re-training done, informs board about the positions and refusals of the trainer to continue in this case, reminds board that there may be a shortage of the support team to be addressed . 2015-09-06 (board): requests to solve shortage of support team by adding two persons, one (who does not have an ABC but support experience) with access to the OTRS one (with an ABC but without support experience) with access to the DB via the support console . 2015-09-07 (A): corrects typo in English transcript . 2015-09-07 (A): follow up ruling II . 2015-09-08 (Vice-president): files incident against follow up ruling II . 2015-09-14 (A): reminds the VP that the ruling can only challenged via appeal, or by addressing the Arbitrator and explaining the issue, addressing auditor is no option; request could be understood as if VP would not accept two recent rulings (this case and a20150420.1); A does not mind if case is reviewed; a VP should be careful to challenge a board-motion beside of filing a dispute against it; this is serious topic, A is interested in good solutions; orders VP to provide his issues until 2015-09-21, so that the ruling could be reconsidered, if this is not done the assumption stands that there are no such issues . 2015-09-14 (Vice-President): mail about ruling was "simple statement that VP has personal objections cause the involved acting persons, that i think it's a violating of our rules, and that i have to inform our internal Auditor about the incident."; it was NOT an appeal; but relevant to audit process; auditor has to file an incident and mention it in his audit-report; "that is all" . 2015-09-14 (A): if VP thinks that there is a need for an incident, arguments are required; addresses role of involved persons; explains decision again; relevant part of mail was if there was a policy violation; a feeling that something is wrong because one does not trust the persons is not enough as a reference; repeats request to provide issues until deadline; agrees that there was something of incident status, ruling and motion were not cause but are meant as a solution; explains situation of support team . 2015-09-15 (A): informs board-public and cacert-inc-members list about ruling and situation of support team, as the motion was discussed there and this is of general interest . 2015-09-16 (A): repeats execution request for follow up ruling II to provide ordered access . 2015-09-17 (Support): confirms execution; access rights were provided . 2015-09-17 (A): thanks support for execution . 2015-09-17 (A): informs cacert-inc-member-list that access for temporary support team members was confiremd and tickets should be handled, again . [a lot of activities affecting this case, mostly done outside of the case - probably some need for documentation] . [some discussion about possible follow up ruling III between (A), board, Support-TL] . 2016-05-27 (A): follow up ruling III . [maybe some minor things] . 2016-06-10 (A): edit to documentation part of process == Related Cases == || [[Arbitrations/a20111128.3|a20111128.3]] || [[Arbitrations/a20111128.3|Delete Account cases to handle by SE - No Assurances given, no certs or certs expired - Precedents Case {i} ]] || || [[Arbitrations/a20140713.1|a20140713.1]] || [[Arbitrations/a20140713.1|delete assurer account]] || || [[Arbitrations/a20141231.1|a20141231.1]] || [[Arbitrations/a20141231.1|no default revokation of assurances if assurer leaves CAcert]] || == Similiar Cases == || [[Arbitrations/a20080702.1|a20080702.1]] || [[Arbitrations/a20080702.1|User requests to delete account with Assurance Points]] || || [[Arbitrations/a20090618.3|a20090618.3]] || [[Arbitrations/a20090618.3|Assurer requests to delete account]] || || [[Arbitrations/a20090328.1|a20090328.1]] || [[Arbitrations/a20090328.1|Assurer wants his account deleted]] || || [[Arbitrations/a20090510.3|a20090510.3]] || [[Arbitrations/a20090510.3|Assurer with alter-ego even assured himself more than once]] || || [[Arbitrations/a20100907.1|a20100907.1]] || [[Arbitrations/a20100907.1|letter of resignation]] || || [[Arbitrations/a20110110.1|a20110110.1]] || [[Arbitrations/a20110110.1|Please Delete my Account (Is Assurer)]] || || [[Arbitrations/a20110131.1|a20110131.1]] || [[Arbitrations/a20110131.1|Account Removal Olivier F (Is Assurer)]] || || [[Arbitrations/a20111004.1|a20111004.1]] || [[Arbitrations/a20111004.1|Assurer requests deletion of his account ]] || || [[Arbitrations/a20130308.1|a20130308.1]] || [[Arbitrations/a20130308.1|Delete Account ]] || || [[Arbitrations/a20140925.3|a20140925.3]] || [[Arbitrations/a20140925.3|delete assurer account Philipp S ]] || || [[Arbitrations/a20140926.1|a20140926.1]] || [[Arbitrations/a20140926.1|delete assurer account Nils E ]] || || [[Arbitrations/a20140926.3|a20140926.3]] || [[Arbitrations/a20140926.3|termination of assurer account Hannes R ]] || || [[Arbitrations/a20140926.4|a20140926.4]] || [[Arbitrations/a20140926.4|termination of assurer account Christoph B ]] || || [[Arbitrations/a20140927.2|a20140927.2]] || [[Arbitrations/a20140927.2|termination of assurer account Federico H ]] || || [[Arbitrations/a20140929.1|a20140929.1]] || [[Arbitrations/a20140929.1|termination of assurer account Fridtjof B ]] || || [[Arbitrations/a20140930.1|a20140930.1]] || [[Arbitrations/a20140930.1|deletion of assurer account Lukas H ]] || || [[Arbitrations/a20141002.1|a20141002.1]] || [[Arbitrations/a20141002.1|terminate assurer account Rutger S]] || || [[Arbitrations/a20141011.1|a20141011.1]] || [[Arbitrations/a20141011.1|delete assurer account Johannes K]] || || [[Arbitrations/a20141020.1|a20141020.1]] || [[Arbitrations/a20141020.1|terminate assurer account Klaus L]] || ---- . CategoryArbitration . CategoryArbCaseAccountDelAssurer