Aller au contenu principal

4. Guidelines for Defining New Subservice Types (4. Lignes directrices pour définir de nouveaux types de sous-services)

4. Guidelines for Defining New Subservice Types (4. Lignes directrices pour définir de nouveaux types de sous-services)

The base YANG module defined in Section 3.3 only defines a single type of subservice that represent service instances. As explained above, this model is meant to be augmented so that a variety of subservices can be used in the assurance graph. In this section, we propose some guidelines for specifying such extensions at IETF.

Le module YANG de base défini dans la section 3.3 définit uniquement un seul type de sous-service qui représente les instances de service. Comme expliqué ci-dessus, ce modèle est destiné à être augmenté afin qu'une variété de sous-services puissent être utilisés dans le graphe d'assurance. Dans cette section, nous proposons quelques lignes directrices pour spécifier de telles extensions à l'IETF.

The mechanism to add a new subservice type is to define a new module for that subservice. The module name should start with "ietf-service-assurance-". The namespace of the module should start with "urn:ietf:params:xml:ns:yang:ietf-service-assurance-". The prefix of the module should start with "sain-". For instance, the subservice type representing the assurance of a device should have:

Le mécanisme pour ajouter un nouveau type de sous-service consiste à définir un nouveau module pour ce sous-service. Le nom du module doit commencer par "ietf-service-assurance-". L'espace de noms du module doit commencer par "urn:ietf:params:xml:ns:yang:ietf-service-assurance-". Le préfixe du module doit commencer par "sain-". Par exemple, le type de sous-service représentant l'assurance d'un dispositif devrait avoir :

  • the name "ietf-service-assurance-device",

  • le nom "ietf-service-assurance-device",

  • the namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance-device", and

  • l'espace de noms "urn:ietf:params:xml:ns:yang:ietf-service-assurance-device", et

  • the prefix "sain-device".

  • le préfixe "sain-device".

The new module should define:

Le nouveau module doit définir :

  • a new identity to represent the new type and

  • une nouvelle identité pour représenter le nouveau type et

  • the parameters fully specifying an instance of the new subservice type.

  • les paramètres spécifiant entièrement une instance du nouveau type de sous-service.

The new identity should be based on the "subservice-base" identity. The name of the identity should end with "-type", for instance, "device-type".

La nouvelle identité doit être basée sur l'identité "subservice-base". Le nom de l'identité doit se terminer par "-type", par exemple, "device-type".

The parameters should be defined in a container named "parameters" that augments the choice "/subservices/subservice/parameter" from the main module. The augmentation should be restricted to cases where the type of the subservice matches the identity representing the new service type.

Les paramètres doivent être définis dans un conteneur nommé "parameters" qui augmente le choix "/subservices/subservice/parameter" du module principal. L'augmentation doit être limitée aux cas où le type de sous-service correspond à l'identité représentant le nouveau type de service.

We define two subservice types in the next sections: the "device" subservice type is defined in Section 5 and the "interface" subservice type is defined is Section 6. These subservices can be taken as examples of the rules defined in this section.

Nous définissons deux types de sous-services dans les sections suivantes : le type de sous-service "device" est défini dans la section 5 et le type de sous-service "interface" est défini dans la section 6. Ces sous-services peuvent être pris comme exemples des règles définies dans cette section.

Vendors can specify their own subservices types by defining the corresponding modules in their own namespace. An example of such a vendor-specific module is specified in Appendix A. Vendors can also augment existing IETF-specified subservices to add their own vendor-specific information.

Les fournisseurs peuvent spécifier leurs propres types de sous-services en définissant les modules correspondants dans leur propre espace de noms. Un exemple d'un tel module spécifique au fournisseur est spécifié dans l'annexe A. Les fournisseurs peuvent également augmenter les sous-services existants spécifiés par l'IETF pour ajouter leurs propres informations spécifiques au fournisseur.