4. Guidelines for Defining New Subservice Types (4. 新しいサブサービスタイプを定義するためのガイドライン)

4. Guidelines for Defining New Subservice Types (4. 新しいサブサービスタイプを定義するためのガイドライン)

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.

セクション 3.3 で定義された基本 YANG モジュールは、サービスインスタンスを表す単一のタイプのサブサービスのみを定義しています。上記のように、このモデルは、保証グラフでさまざまなサブサービスを使用できるように拡張されることを意図しています。このセクションでは、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:

新しいサブサービスタイプを追加するメカニズムは、そのサブサービスの新しいモジュールを定義することです。モジュール名は "ietf-service-assurance-" で始まる必要があります。モジュールの名前空間は "urn:ietf:params:xml:ns:yang:ietf-service-assurance-" で始まる必要があります。モジュールのプレフィックスは "sain-" で始まる必要があります。たとえば、デバイスの保証を表すサブサービスタイプには、以下のものが必要です。

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

• 名前 "ietf-service-assurance-device"、

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

• 名前空間 "urn:ietf:params:xml:ns:yang:ietf-service-assurance-device"、および

• the prefix "sain-device".

• プレフィックス "sain-device"。

The new module should define:

新しいモジュールでは、以下を定義する必要があります。

• a new identity to represent the new type and

• 新しいタイプを表す新しい識別子、および

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

• 新しいサブサービスタイプのインスタンスを完全に指定するパラメータ。

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

新しい識別子は、"subservice-base" 識別子に基づいている必要があります。識別子の名前は、たとえば "device-type" のように "-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.

パラメータは、メインモジュールの選択肢 "/subservices/subservice/parameter" を拡張する "parameters" という名前のコンテナで定義する必要があります。拡張は、サブサービスのタイプが新しいサービスタイプを表す識別子と一致する場合に制限する必要があります。

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.

次のセクションで 2 つのサブサービスタイプを定義します。"device" サブサービスタイプはセクション 5 で定義され、"interface" サブサービスタイプはセクション 6 で定義されます。これらのサブサービスは、このセクションで定義されたルールの例として見ることができます。

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.

ベンダーは、独自の名前空間で対応するモジュールを定義することにより、独自のサブサービスタイプを指定できます。このようなベンダー固有のモジュールの例は、付録 A に指定されています。ベンダーは、既存の IETF 指定のサブサービスを拡張して、独自のベンダー固有情報を追加することもできます。