1 / 6

Headgroup Meeting

This meeting will discuss the planning and test resources for Inet Releases, as well as updates to the PoA process, including electronic signatures and emergency porting.

karenmorris
Download Presentation

Headgroup Meeting

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Headgroup Meeting Anne-Catherine Christen Managing Director Teldas 24th March 2017

  2. Agenda • Inet-Releases: Planning / Test Resources • ONP PoA Process: electronic signature / ONP document for Implementation • ONP Emergency Porting Process • Inet-Statistics 2016 • AoB & Open Actions

  3. Inet-Releases • Inet-Release 2016 was a challenging release, with important changes on ONP processes and SSH interface • In 2017, we implemented already 2 packages of changes: • Pack1 on 13.2.2017 (supervisor menu, select WO “do I have to react?”…) • Pack2 on 21.3.2017 (cdr and vta file counter and archiving mechanism) • Other changes for 2017: • Apache migration (under evaluation) • New Test environment (under evaluation) • Security Audit follow-up actions (under evaluation) • Small bug fixes (PR10700…) and changes (to be evaluated) • Inet-Release 2018: • Any new change requests ? • Headgroup members should open possible CRs until September

  4. Test Resources • Testing of the Release changes (Teldas view): • Validation of implementation towards the specifications / technical documents • Tests must be done early to have time for bug fixes • Teldas more and more involved in the testing phases of Inet-releases. In 2016, most test cases were first tested by Teldas prior to testing by WG members. Most PRs were opened by Teldas • Testing of the Release changes (Operators view): • WG members explain that they have often no resources, it is not a priority internally, • Operators are mainly interested in doing some regression tests for their main processes (to check that the processes still work) • When a new feature is introduced and an operator is interested to use it (or obliged to use it), then the operator is interested in testing that it works as expected • Operators want to validate their internal interface changes towards Inet How to reconcile both needs?

  5. Example Pack1 and Pack2 • In 2017, we implemented several changes via small maintenance windows • Tests for Pack 1 was nearly exclusively done by Teldas • Tests for Pack 2 was also mostly done by Teldas • Teldas requires more test resources in future? • Are operators ready to leave the whole responsibility to Teldas ? (e.g. if operators don’t test properly towards their own interfaces and processes, they might face issues after rollout) • Go/no go decision exclusively at Teldas ? (or involve WG?)

  6. PoAProcess (recommendation WG) • PoA : Replace in the documentation the general term valid “signature” by “valid approval” • For Business customers (=INA; DDI and subscribers with “company name”): • physical signature still required –> no change • For residential customers: • Valid service contract with recipient • Same subscriber consent validation process applies for PoA • PoA document still needed (can be a part of the service contract) with the same fields as currently agreed. Field “PoA Signature” can then contain “subscriber has accepted the porting conditions on date/time XXX via Sales Channel XX”) • The “early contract termination process” must be offered as an exception and clearly validated by the subscriber (e.g. must click on “yes I’m aware of possible early termination fees which I will have to pay at my present operator”) • If reject 001 (wrong name): a legally valid signature (physical or e-signature) is required from the subscriber • If abuse: Recipient must accept an emergency port-back

More Related