Un registre, par exemple un registre de noms de
domaine, utilise parfois le protocole
EPP pour la communication avec ses
clients. Ce RFC décrit comment utiliser ce
protocole pour informer les clients des périodes d'indisponibilité
du registre, par exemple lors d'une opération de maintenance.
Aujourd'hui, un registre prévient de ses periodes
d'indisponibilité prévues par divers moyens : courriers aux BE, messages sur des
réseaux sociaux, page Web dédiée comme :
Chaque registre le
fait de façon différente, il n'existe pas de règles communes, et le
côté non-structuré de ces annonces fait qu'il faut une interventon
humaine pour les analyser et les mettre dans un agenda. Et un
BE peut devoir
interagir avec de nombreux registres ! Notre RFC propose d'utiliser
EPP
(RFC 5730) pour ces annonces.
Donc, premier principe, puisqu'on va souvent manipuler des dates,
les dates et heures seront toutes représentées en UTC et dans le format
du RFC 3339. Ensuite, les annonces seront dans
un élément XML urn:ietf:params:xml:ns:epp:maintenance-1.0
(enregistré
à l'IANA). Parmi les sous-éléments de cet élément :
id, un identificateur de
l'évènement,systems, qui permettra de désigner les
systèmes affectés,environment, pour dire si l'évènement
concerne la production ou bien un banc de test,start et end, qui
indiquent le début et la fin (prévue…) de l'évènement,- et plusieurs autres éléments.
Un exemple d'évènement, une intervention sur le serveur EPP
epp.registry.example de production, peut être :
2e6df9b0-4092-4491-bcc8-9fb2166dcee6
EPP
epp.registry.example
full
2021-12-30T06:00:00Z
2021-12-30T07:00:00Z
planned
https://www.registry.example/notice?123
example
test
On voit que le serveur EPP sera arrêté pendant une heure
(
full indiquant
une indisponibilité totale) et que cela affectera les TLD
.example et
.test. Une
telle information, étant sous une forme structurée, peut être
analysée par un programme et automatiquement insérée dans un agenda,
ou un système de supervision.
Les commandes EPP exactes, maintenant (section 4 du RFC). La
commande 2e6df9b0-4092-4491-bcc8-9fb2166dcee6 :
2e6df9b0-4092-4491-bcc8-9fb2166dcee6
Puis la réponse du serveur :
Command completed successfully
2e6df9b0-4092-4491-bcc8-9fb2166dcee6
Routine Maintenance
EPP
epp.registry.example
full
2021-12-30T06:00:00Z
2021-12-30T07:00:00Z
planned
https://www.registry.example/notice?123
free-text
Freitext
example
test
false
false
2021-11-08T22:10:00Z
...
Ici, le client connaissait l'identificateur d'une opération de
maintenance particulière. S'il ne le connait pas et veut récupérer
une liste d'événements :
Il récupérera alors une
, une
liste d'opérations de maintenance.
Le client EPP peut
également être prévenu des maintenances par la commande
Command completed successfully; ack to dequeue
2021-11-08T22:10:00Z
Registry Maintenance Notification
2e6df9b0-4092-4491-bcc8-9fb2166dcee6
create
EPP
epp.registry.example
full
...
La section 5 du RFC décrit la syntaxe formelle de cette extension
(en XML Schema). Elle est dans le
registre IANA des extensions à EPP.
Et question mises en œuvre ? Apparemment, les registres gérés par
GoDaddy et Tango envoient déjà ces
informations de maintenance.
