[Titel van het document]

Dit document beschrijft hoe Logius, afdeling Standaarden (hierna: Logius) xxxxx standaard beheert en hoe de bijbehorende governance is ingericht.

Beschrijf hier de standaard

Logius richt de beheerorganisatie in conform het Beheer en Ontwikkel Model voor Open Standaarden (BOMOS). Ook het beheer van de xxxxx is op basis van BOMOS ingericht. Voor de beheerorganisatie heeft Logius een generiek beheermodel opgezet, waar het beheerplan van xxx is afgeleid.

Figuur 1 Bomos model

Voor meer informatie over BOMOS zie ook:

BOMOS, het fundament

BOMOS, de verdieping

'Publicatie-BOMOS-2i.pdf'

BOMOS onderscheidt verschillende levenscyclusfases waarin een standaard zich kan bevinden. Deze fase bepaalt mede op welke beheeronderdelen meer of minder wordt ingezet. De verschillende fases zijn:

1. Creatie/ontwikkeling
2. Introductie
3. Implementatie/groei
4. Volwaardige toepassing
5. Uitfaseren

Adoptie

Tijd

Figuur 2 Bomos levenscyclus

De xxx bevindt zich in de xxx fase. De eerste versie van de standaard is xxx aangemeld bij het Forum Standaardisatie en op xxx op de lijst van verplichte standaarden opgenomen. Vanuit het xxx en Logius afdeling Standaarden wordt momenteel nog volop aan de xxx gewerkt en de verwachting is dat de standaard nog de nodige ontwikkelingen door gaat maken.

Daarom is er komende tijd vooral aandacht voor:

Het in de praktijk bestendigen van het beheer van de standaard; Gestaag doorontwikkeling van de specificaties zelf;

Bouwen en aanbieden ondersteunende tooling; Groei in het aantal toepassingen van de standaard; Monitoring van het gebruik van de standaard; Groei van de community rond de standaard.

Met de xxx standaard wil de Nederlandse overheid interoperabiliteit bevorderen. Dit komt erop neer dat overheden dezelfde standaard in vergelijkbare situaties toepassen. Dit maakt uiteindelijk dat componenten en systemen onderling effectief gegevens uit kunnen wisselen. Zowel horizontaal in één voorziening binnen één situatie als verticaal tussen voorzieningen in verschillende situaties en tussen organisaties. Deze doelstelling wordt onderschreven door een breed scala aan partijen die deelnemen aan het xxx Kennisplatform, waar de ontwikkeling van de standaard zijn oorsprong heeft, en is bestendigd door Forum

Standaardisatie en het OverheidsBrede Beleidsoverhed Digitale Overheid (OBDO), die xxxx standaard hebben opgenomen op de zogenaamde ‘pas toe of leg uit’-lijst met andere standaarden die interoperabiliteit bevorderen zie ook de basisinformatie van het Forum Standaardisatie.

De toetsingsprocedure voor opname van een standaard op pas toe of leg uit lijst bestaat uit de volgende

stappen:

1. Aanmelding
2. Intake
3. Expertonderzoek
4. Openbare consultatie
5. Advisering door het Forum Standaardisatie
6. Vaststelling door het Overheidsbreed Beleidsoverleg Digitale Overheid

Deze criteria staan op: Toetsingsprocedure en criteria voor lijsten met open standaarden (forumstandaardisatie.nl)

De afdeling Standaarden van Logius werkt samen met het Forum Standaardisatie aan de promotie van open standaarden via kennisplatforms, bijeenkomsten en seminars. De standaarden die Logius beheert, zijn verplichte standaarden voor overheidsorganisaties en staan op de 'Pas toe of leg uit'-lijst van het Forum of zijn verplicht via wetgeving.

Het beheer van de xxx standaard wordt gefinancierd door min. BZK voor een initiële periode van tenminste drie jaar (2020-2023) om gebruikers het vertrouwen te geven dat er geen desinvesteringen worden gedaan bij het implementeren van de standaard. Na drie jaar wordt de financiering verlengd als blijkt dat het nut van en de behoefte aan de standaard nog aanwezig is.

De xxx community/ Interesse Groep bestaat uit eenieder die belanghebbende of belangstellende is m.b.t. de standaard. Deelname aan de community kent geen drempels of restricties. Leden van de community kunnen alle informatie m.b.t. de standaard en het beheer daarvan inzien via de website en via verschillende kanalen issues of RFC's melden. Daarnaast kunnen community leden reageren op openbare consultaties en onder bepaalde voorwaarden deelnemen aan de Technische Architectuur Groep (zie paragraaf deelname).

Beschrijf hoe de standaard zich verhoudt tot de enterprise en domein-architecturen.

De xxx standaard heeft de 'pas toe of leg uit' -status van Forum Standaardisatie. Dit betekent kort gezegd dat Nederlandse overheidspartijen en partijen uit de (semi) publieke sector deze standaard dienen toe te passen op het moment dat zij hun informatie met behulp van xxx standaard willen ontsluiten. Zie hoofdstuk 1 voor meer informatie.

1. Uitbreidingen en aanpassingen in de xxx standaarden komen tot stand door participatie van de verschillende belanghebbenden.

2. Belanghebbenden kunnen op vier manieren participeren: als lid van de xxx Community en/of de Technische Architectuur Groep en/of als lid van de Adviesraad of als lid van het OBDO.

RFC's kunnen binnen komen via verschillende kanalen:

1. Rechtstreeks bij de beheerorganisatie, tijdens overleggen, via de website of mail

2. Bij de werkgroep xxx van de standaard en tijdens overleggen, via de website of mail

Logius, afdeling standaarden onderscheid vier statussen die de xxx standaard kan hebben:

Voorbeeld tekst: Logius biedt momenteel geen opleiding aan, maar borgt dat de informatie m.b.t. de standaard altijd, zonder drempels, toegankelijk is. Bovendien kunnen geïnteresseerden via verschillende kanalen contact opnemen met Logius in geval van vragen of opmerkingen. Zie hiervoor 5.2 Helpdesk.

Aanvullend organiseert het Kennisplatform/community regelmatig overleggen en seminars m.b.t. de xxx standaard.

Logius biedt ondersteuning en advies via verschillende kanalen:

Online: als reactie op issue's in de Github van het Kennisplatform:

xxxxx

Per mail: xxx

Telefonisch: xxxx

Per post: xxxx

Voorbeeld tekst: Met xxx worden standaardisatiecommunities ondersteund en geïnspireerd bij het structureel vormgeven van het beheer en verdere ontwikkelingen van standaarden. xxx is niet verplicht en is ook geen conformiteitsbeoordeling.

xxx kan op verschillende manieren gebruikt worden:

• voor het opzetten van beheer van standaarden of stelsels

• als hulpmiddel voor verdere ontwikkeling van beheerorganisaties

• als richtlijn om aan te voldoen

• als onderbouwing voor het aanvragen van de status ‘Uitstekend Beheer’ van uw standaard bij Forum Standaardisatie

• als inspirerend naslagwerk

Voorbeeld tekst:

Certificatie van xxx is op dit moment niet mogelijk. Wel is het mogelijk xxx te valideren en te testen met behulp van xxx tools welke beschikbaar zijn op:

• voorbeeld &

• voorbeeld

Na validatie met de API-test tool is het mogelijk een badge te genereren waarmee aangetoond wordt dat de API voldoet aan alle test voorwaarden.

De xxx-standaard wordt via verschillende kanalen gepromoot. Ten eerste via het Kennisplatform/community. Naast communicatie op de website van het kennisplatform/community, organiseert het platform regelmatig vrij toegankelijke bijeenkomsten.

Daarnaast heeft de standaard de zogenaamde 'pas toe of leg uit' -status van Forum Standaardisatie. Dit betekent dat Forum Standaardisatie het gebruik van deze standaard niet alleen actief promoot, maar in veel gevallen zelfs hard voorschrijft.

Tot slot is Logius promotor van de standaard. Zowel intern voor de toepassing van de standaard in Logius voorzieningen als extern, door andere partijen te informeren en adviseren over de mogelijkheden van de standaard.

Als een nieuwe versie van de xxx standaard de status "In Gebruik" heeft, worden verschillende zaken gepubliceerd.

Logius publiceert altijd de volledige specificatie van de standaard op een deel van zijn website. Daarnaast wordt een persbericht uitgegeven, waarin de publicatie van de nieuwe release van de standaard wordt aangekondigd. Aanvullend publiceert Logius alle genoemde documentatie zoals genoemd bijDocumentatie.

Klachten over de opzet of de uitvoering van het beheerproces kunnen ingediend worden bij Logius. Dit kan in principe via alle beschikbare kanalen (zie bij 5.2). De indiener van de klacht krijgt zo spoedig mogelijk en altijd terugkoppeling over de voortgang van en beslissing over zijn klacht.

De volledige klachtenprocedure is terug te vinden in het generieke beheermodel van Logius, afdeling standaarden. (volgt)

↑

Per document wordt met [documentnaam]_vX.Y.Z de versie aangegeven. Met vX.Y.Z wordt gerefereerd aan major (X) en minor (Y) releases en (Z) patches, dit wordt hieronder toegelicht:

In een patchrelease worden wijzigingen doorgevoerd die de technische specificatie niet raken. Dit kunnen tekstuele wijzigen zijn of inhoudelijke indelingen van de standaard. De wijzigen worden vastgelegd in release notes. Een patch releases wordt door de beheerder op eigen initiatief of op aanwijzingen van gebruikers doorgevoerd en gepubliceerd. Een patchrelease wordt aan de Technische Architectuurgroep ter kennisgeving medegedeeld. Een nieuwe patchrelease vervangt een eerdere versie in zijn geheel.

In een minor release kunnen wijzigingen doorgevoerd worden die de technische specificatie raken. Dat kunnen fouten zijn in de specificatie zijn, het verzwaren of verlichten van een restrictie of het een aanpassing van een beveiligingstandaard (zoals TLS 1.2 naar TLS 1.3). In de SEMVER aanpak zijn minor releases backwards compatible. Voor een standaard is backwards compatibility lastiger te bepalen omdat uiteindelijk twee partijen met elkaar moeten meebewegen. Het is de intentie dat Minor Releases niet backwards incompatible zijn. Voor Minor Releases wordt een uitgebreid vaststellings-procedure gevolgd conform het beheermodel en er kan in overleg met de stakeholders tot een migratiepad worden besloten. Dit migratiepad wordt in de release meegenomen.

Er zijn twee Major release momenten: de overgang naar nieuwe internationale standaarden binnen een bestaand profiel, bijvoorbeeld HTTP 2.0 of de toevoeging van een geheel nieuwe regel of profiel binnen de standaard. In het eerste geval komt er een nieuw major versie van de standaard om vast te stellen volgens het de reguliere vaststellingsprocedure (conform het Beheermodel). In het tweede geval wordt er een nieuw document of nieuwe sectie toegevoegd aan de standaard.

Als hierbij het functionele toepassingsgebied van de standaard, waarvoor het pas toe of leg uit regime geldt, veranderd, dan wordt eerst de uitgebreide vaststellingsprocedure gevolgd en vervolgens de procedure van het Forum Standaardisatie.

Een versie van een standaard (versie 1.2.0) is compatible met een eerdere versie van een standaard (versie 1.1.0) als uitwerkingen/ implementaties volgens de eerdere versie 1.1.0 ook volledig voldoen aan de normen en eisen van versie 1.2.0 .

Wijzigingen in de standaard kunnen impact hebben op de technische werking van implementaties en/of op afspraken die de technische werking van implementaties niet raken bv organisatorische of proces afspraken;

Voor standaarden is relevant of een realisatie volgens de oude versie van een standaard wel of niet voldoet aan de nieuwe versie van de standaard:

Globale regels voor het bepalen van de impact op de versionering:

• Toevoegen = Major
• Wijzingen :
  • Versoepeling = Minor
  • Verscherping = Major
• Verwijderen = Minor
• Correctie = Patch

Wanneer een nieuwe major versie uitkomt zal de oude versie conform de afgestemde migratiepad een einddatum van geldigheid krijgen. In de overgangsperiode kunnen dus meerdere versies gepubliceerd zijn en de status geldig hebben.

Om te kunnen werken aan publicatie-, werk- en voorstelversies van documenten worden Git branches gebruikt.

Voorbeeld In het onderstaande voorbeeld zien wij een standaard van 1.0.0 naar 1.1.0 ontwikkelen.

De branch main is de huidig gepubliceerde versie en de branch develop is de werkversie. Het uitwerken van een RFC gebeurt in een afsplitsing van de develop branch waarna het terug de develop branch invloeit. In het voorbeeld schema leidde RFC1 tot de eerste release candidate (rc) van versie 1.1.0 van de standaard. Wanneer de werkversie gereed en akkoord is als release stromen de wijzigingen naar de branch main.

Het kan voorkomen dat gewenst wordt vlug een kleine (niet inhoudelijke) aanpassing aan de gepubliceerde versie te maken. Om bijvoorbeeld een spelfout vlug te corrigeren kan deze aanpassing op main i.p.v. develop worden uitgevoerd. In het voorbeeld leidde een hotfix tot een release van versie 1.0.1 waarna de aanpassing naar de werkversie geduwd wordt.