4. Guidelines for Defining New Subservice Types (4. Richtlinien zur Definition neuer Subservice-Typen)
4. Guidelines for Defining New Subservice Types (4. Richtlinien zur Definition neuer Subservice-Typen)
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.
Das in Abschnitt 3.3 definierte Basis-YANG-Modul definiert nur einen einzigen Subservice-Typ, der Serviceinstanzen repräsentiert. Wie oben erläutert, soll dieses Modell erweitert werden, damit eine Vielzahl von Subservices im Assurance-Graphen verwendet werden kann. In diesem Abschnitt schlagen wir einige Richtlinien für die Spezifikation solcher Erweiterungen bei der IETF vor.
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:
Der Mechanismus zum Hinzufügen eines neuen Subservice-Typs besteht darin, ein neues Modul für diesen Subservice zu definieren. Der Modulname sollte mit "ietf-service-assurance-" beginnen. Der Namespace des Moduls sollte mit "urn:ietf:params:xml:ns:yang:ietf-service-assurance-" beginnen. Das Präfix des Moduls sollte mit "sain-" beginnen. Beispielsweise sollte der Subservice-Typ, der die Assurance eines Geräts repräsentiert, Folgendes haben:
-
the name "ietf-service-assurance-device",
-
den Namen "ietf-service-assurance-device",
-
the namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance-device", and
-
den Namespace "urn:ietf:params:xml:ns:yang:ietf-service-assurance-device", und
-
the prefix "sain-device".
-
das Präfix "sain-device".
The new module should define:
Das neue Modul sollte definieren:
-
a new identity to represent the new type and
-
eine neue Identität, um den neuen Typ zu repräsentieren, und
-
the parameters fully specifying an instance of the new subservice type.
-
die Parameter, die eine Instanz des neuen Subservice-Typs vollständig spezifizieren.
The new identity should be based on the "subservice-base" identity. The name of the identity should end with "-type", for instance, "device-type".
Die neue Identität sollte auf der Identität "subservice-base" basieren. Der Name der Identität sollte auf "-type" enden, zum Beispiel "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.
Die Parameter sollten in einem Container namens "parameters" definiert werden, der die Auswahl "/subservices/subservice/parameter" aus dem Hauptmodul erweitert. Die Erweiterung sollte auf Fälle beschränkt werden, in denen der Typ des Subservices mit der Identität übereinstimmt, die den neuen Servicetyp repräsentiert.
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.
Wir definieren in den nächsten Abschnitten zwei Subservice-Typen: Der Subservice-Typ "device" wird in Abschnitt 5 definiert und der Subservice-Typ "interface" wird in Abschnitt 6 definiert. Diese Subservices können als Beispiele für die in diesem Abschnitt definierten Regeln herangezogen werden.
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.
Hersteller können ihre eigenen Subservice-Typen spezifizieren, indem sie die entsprechenden Module in ihrem eigenen Namespace definieren. Ein Beispiel für ein solches herstellerspezifisches Modul ist in Anhang A spezifiziert. Hersteller können auch bestehende IETF-spezifizierte Subservices erweitern, um ihre eigenen herstellerspezifischen Informationen hinzuzufügen.