4. Guidelines for Defining New Subservice Types (4. Linee Guida per Definire Nuovi Tipi di Sottoservizi)

4. Guidelines for Defining New Subservice Types (4. Linee Guida per Definire Nuovi Tipi di Sottoservizi)

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.

Il modulo base YANG definito nella Sezione 3.3 definisce solo un singolo tipo di sottoservizio che rappresenta le istanze di servizio. Come spiegato sopra, questo modello è inteso per essere aumentato in modo che una varietà di sottoservizi possa essere utilizzata nel grafo di assurance. In questa sezione, proponiamo alcune linee guida per specificare tali estensioni presso 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:

Il meccanismo per aggiungere un nuovo tipo di sottoservizio è definire un nuovo modulo per quel sottoservizio. Il nome del modulo dovrebbe iniziare con "ietf-service-assurance-". Il namespace del modulo dovrebbe iniziare con "urn:ietf:params:xml:ns:yang:ietf-service-assurance-". Il prefisso del modulo dovrebbe iniziare con "sain-". Ad esempio, il tipo di sottoservizio che rappresenta l'assurance di un dispositivo dovrebbe avere:

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

• il nome "ietf-service-assurance-device",

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

• il namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance-device", e

• the prefix "sain-device".

• il prefisso "sain-device".

The new module should define:

Il nuovo modulo dovrebbe definire:

• a new identity to represent the new type and

• una nuova identità per rappresentare il nuovo tipo e

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

• i parametri che specificano completamente un'istanza del nuovo tipo di sottoservizio.

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 nuova identità dovrebbe essere basata sull'identità "subservice-base". Il nome dell'identità dovrebbe terminare con "-type", ad esempio, "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.

I parametri dovrebbero essere definiti in un contenitore chiamato "parameters" che aumenta la scelta "/subservices/subservice/parameter" dal modulo principale. L'aumento dovrebbe essere limitato ai casi in cui il tipo di sottoservizio corrisponde all'identità che rappresenta il nuovo tipo di servizio.

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.

Definiamo due tipi di sottoservizi nelle sezioni successive: il tipo di sottoservizio "device" è definito nella Sezione 5 e il tipo di sottoservizio "interface" è definito nella Sezione 6. Questi sottoservizi possono essere presi come esempi delle regole definite in questa sezione.

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.

I venditori possono specificare i propri tipi di sottoservizi definendo i moduli corrispondenti nel proprio namespace. Un esempio di tale modulo specifico del venditore è specificato nell'Appendice A. I venditori possono anche aumentare i sottoservizi specificati da IETF esistenti per aggiungere le proprie informazioni specifiche del venditore.