[要約] RFC 8412は、PA-TNCのためのソフトウェアインベントリメッセージと属性（SWIMA）に関する規格であり、SWIMAメッセージの構造と属性の定義を提供します。その目的は、ネットワークデバイスのソフトウェア構成情報を収集し、セキュリティポリシーの適用や脆弱性管理に役立つことです。
Internet Engineering Task Force (IETF) C. Schmidt
Request for Comments: 8412 D. Haynes
Category: Standards Track C. Coffin
ISSN: 2070-1721 The MITRE Corporation
D. Waltermire
National Institute of Standards and Technology
J. Fitzgerald-McKay
United States National Security Agency
July 2018
Software Inventory Message and Attributes (SWIMA) for PA-TNC
PA-TNCのソフトウェアインベントリメッセージと属性（SWIMA）
Abstract
概要
This document extends "PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)" (RFC 5792) by providing specific attributes and message exchanges to allow endpoints to report their installed software inventory information to a NEA Server, as defined in "Network Endpoint Assessment (NEA): Overview and Requirements" (RFC 5209).
このドキュメントは、エンドポイントがインストール済みのソフトウェアインベントリ情報をNEAサーバーに報告できるように特定の属性とメッセージ交換を提供することにより、「PA-TNC：Trusted Network Connect（TNC）と互換性のあるポスチャ属性（PA）プロトコル」（RFC 5792）を拡張します。 「ネットワークエンドポイントアセスメント（NEA）：概要と要件」（RFC 5209）で定義されています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8412.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8412で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Network Endpoint Assessment (NEA) ..........................6
1.2. Conventions Used in This Document ..........................7
1.3. Definitions ................................................7
2. Background ......................................................8
2.1. Supported Use Cases ........................................8
2.1.1. Use Software Inventory as an Access Control Factor ..8
2.1.2. Central Stores of Up-to-Date Endpoint
Software Inventory Data .............................9
2.1.3. PA-TNC Use Cases ....................................9
2.2. Use Cases That Are Not Supported ...........................9
2.3. SWIMA Requirements ........................................10
2.4. Non-SWIMA Requirements ....................................11
2.5. Assumptions ...............................................12
2.6. Assumptions Not Made ......................................12
3. System Requirements ............................................12
3.1. Data Sources ..............................................13
3.2. Data Models ...............................................14
3.3. Basic Attribute Exchange ..................................16
3.4. Core Software-Reporting Information .......................17
3.4.1. Software Identifiers ...............................17
3.4.2. Data Model Type ....................................19
3.4.3. Record Identifiers .................................19
3.4.4. Software Locators ..................................20
3.4.5. Source Identifiers .................................21
3.4.6. Using Software and Record Identifiers in
SWIMA Attributes ...................................22
3.5. Targeted Requests .........................................22
3.6. Monitoring Changes in an Endpoint's Software
Inventory Evidence Collection .............................23
3.7. Reporting Change Events ...................................26
3.7.1. Event Identifiers ..................................27
3.7.2. Core Event-Tracking Information ....................28
3.7.3. Updating Inventory Knowledge Based on Events .......29
3.7.4. Using Event Records in SWIMA Attributes ............29
3.7.5. Partial and Complete Lists of Event Records
in SWIMA Attributes ................................30
3.7.6. Synchronizing Event Identifiers and Epochs .........32
3.8. Subscriptions .............................................33
3.8.1. Establishing Subscriptions .........................34
3.8.2. Managing Subscriptions .............................35
3.8.3. Terminating Subscriptions ..........................36
3.8.4. Subscription Status ................................36
3.8.5. Fulfilling Subscriptions ...........................37
3.8.5.1. Subscriptions That Report Inventories .....38
3.8.5.2. Subscriptions That Report Events ..........38
3.8.5.3. Targeted Subscriptions ....................40
3.8.5.4. No Subscription Consolidation .............40
3.8.5.5. Delayed Subscription Fulfillment ..........41
3.9. Error Handling ............................................41
4. Protocol .......................................................43
4.1. Direct Response to a SWIMA Request ........................44
4.2. Subscription-Based Response ...............................45
4.3. Required Exchanges ........................................45
5. Software Inventory Messages and Attributes .....................46
5.1. PA Subtype (aka PA-TNC Component Type) ....................46
5.2. SWIMA Attribute Overview ..................................46
5.3. Message Diagram Syntax ....................................48
5.4. Normalization of Text Encoding ............................49
5.5. Request IDs ...............................................49
5.6. SWIMA Request .............................................50
5.7. Software Identifier Inventory .............................54
5.8. Software Identifier Events ................................58
5.9. Software Inventory ........................................64
5.10. Software Events ..........................................67
5.11. Subscription Status Request ..............................72
5.12. Subscription Status Response .............................73
5.13. Source Metadata Request ..................................75
5.14. Source Metadata Response .................................76
5.15. PA-TNC Error as Used by SWIMA ............................78
5.15.1. SWIMA_ERROR, SWIMA_SUBSCRIPTION_DENIED_ERROR, and
SWIMA_SUBSCRIPTION_ID_REUSE_ERROR Information .....81
5.15.2. SWIMA_RESPONSE_TOO_LARGE_ERROR Information ........83
5.15.3. SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR Information ..85
6. Supported Data Models ..........................................87
6.1. ISO 2015 SWID Tags Using XML ..............................87
6.1.1. Guidance on Normalizing Source Data to ISO 2015
SWID Tags Using XML ................................87
6.1.2. Guidance on Creation of Software Identifiers from
ISO 2015 SWID Tags .................................88
6.2. ISO 2009 SWID Tags Using XML ..............................88
6.2.1. Guidance on Normalizing Source Data to ISO 2009
SWID Tags Using XML ................................88
6.2.2. Guidance on Creation of Software Identifiers from
ISO 2009 SWID Tags .................................89
7. Relationship to Other Specifications ...........................89
8. Security Considerations ........................................90
8.1. Evidentiary Value of Software Inventory Evidence Records ..90
8.2. Sensitivity of Collected Records ..........................91
8.3. Integrity of Endpoint Records .............................92
8.4. SWIMA-PC Access Permissions ...............................92
8.5. Sanitization of Record Fields .............................93
8.6. PA-TNC Security Threats ...................................93
9. Privacy Considerations .........................................93
10. IANA Considerations ...........................................94
10.1. Guidance for the Designated Experts ......................94
10.2. PA Subtypes ..............................................95
10.3. PA-TNC Attribute Types ...................................96
10.4. PA-TNC Error Codes .......................................97
10.5. Software Data Model Types ................................97
11. References ....................................................98
11.1. Normative References .....................................98
11.2. Informative References ...................................99
Authors' Addresses ...............................................101
Knowing the list of software installed on endpoints is useful to understand and maintain the security state of a network. For example, if an enterprise policy requires the presence of certain software and prohibits the presence of other software, reported software installation information can be used to indicate compliance and non-compliance with these requirements. Endpoint software installation inventory lists (hereinafter "software inventories") can further be used to determine an endpoint's exposure to attack based on comparison of vulnerability or threat alerts against identified software's patch-level data. These are some of the highly useful management use cases supported by software inventory data.
エンドポイントにインストールされているソフトウェアのリストを知ることは、ネットワークのセキュリティ状態を理解して維持するのに役立ちます。たとえば、企業ポリシーが特定のソフトウェアの存在を要求し、他のソフトウェアの存在を禁止している場合、報告されたソフトウェアインストール情報を使用して、これらの要件への準拠と非準拠を示すことができます。エンドポイントソフトウェアのインストールインベントリリスト（以下「ソフトウェアインベントリ」）をさらに使用して、特定されたソフトウェアのパッチレベルデータに対する脆弱性または脅威のアラートの比較に基づいて、エンドポイントの攻撃への露出を判断できます。これらは、ソフトウェアインベントリデータでサポートされている非常に有用な管理ユースケースの一部です。
Software Inventory Message and Attributes (SWIMA) for PA-TNC (see "PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)" [RFC5792]) provides a standardized method for exchanging software inventory data that includes a unique Software Identifier associated with a specific version of a software product. SWIMA can also convey metadata about software products beyond this identifier. SWIMA enables software identification, installation, and characterization information to be transported to a central server from any endpoint that supports this specification. Such information can come from multiple sources, including tag files (such as ISO Software Identification (SWID) tags [SWID15]), reports from third-party inventory tools, output from package managers, and other sources. SWIMA does not standardize how software is detected, instead relying on a set of "data sources" to provide information about installed software. SWIMA provides a flexible transport capable of conveying this information, regardless of how it is expressed.
PA-TNCのソフトウェアインベントリメッセージと属性（SWIMA）（「PA-TNC：トラステッドネットワークコネクト（TNC）と互換性のあるポスチャ属性（PA）プロトコル」[RFC5792]を参照）は、以下を含むソフトウェアインベントリデータを交換するための標準化された方法を提供しますソフトウェア製品の特定のバージョンに関連付けられた一意のソフトウェア識別子。 SWIMAは、この識別子を超えてソフトウェア製品に関するメタデータを伝えることもできます。 SWIMAを使用すると、ソフトウェアの識別、インストール、および特性の情報を、この仕様をサポートする任意のエンドポイントから中央サーバーに転送できます。このような情報は、タグファイル（ISOソフトウェア識別（SWID）タグ[SWID15]など）、サードパーティのインベントリツールからのレポート、パッケージマネージャーからの出力、その他のソースを含む、複数のソースから取得できます。 SWIMAはソフトウェアの検出方法を標準化していません。代わりに、インストールされたソフトウェアに関する情報を提供するために一連の「データソース」に依存しています。 SWIMAは、表現方法に関係なく、この情報を伝達できる柔軟なトランスポートを提供します。
This specification is designed to only report software that is installed on a target endpoint. In particular, it does not monitor or report information about what software is running on the endpoint. Likewise, it is not intended to report individual files, libraries, installation packages, or similar artifacts. While all of this information has its uses, this information requires different metadata and monitoring methods. As a result, this specification focuses solely on software inventory information, leaving the reporting of other classes of endpoint information to other specifications.
この仕様は、ターゲットエンドポイントにインストールされているソフトウェアのみを報告するように設計されています。特に、エンドポイントで実行されているソフトウェアに関する情報を監視または報告しません。同様に、個々のファイル、ライブラリ、インストールパッケージ、または同様のアーティファクトを報告することも意図されていません。この情報にはすべて用途がありますが、この情報にはさまざまなメタデータと監視方法が必要です。結果として、この仕様はソフトウェアインベントリ情報にのみ焦点を当て、他のクラスのエンドポイント情報の報告は他の仕様に任せています。
Note that while this specification focuses on "software inventory", the mechanisms it describes could also be used to convey information about firmware and operating systems associated with an endpoint. The focus on software throughout this document should not be read as excluding the use of SWIMA for these other purposes.
この仕様は「ソフトウェアインベントリ」に焦点を当てていますが、この仕様が説明するメカニズムは、エンドポイントに関連付けられたファームウェアとオペレーティングシステムに関する情報を伝達するためにも使用できます。このドキュメント全体でソフトウェアに焦点を当てているのは、これらの他の目的でSWIMAを使用することを除外するものではありません。
This specification defines a new set of PA-TNC attributes; these attributes are used to communicate requests for software inventory information and software installation change events. The exchange of these messages allows software inventory information to be sent to a Network Endpoint Assessment (NEA) Server, which can make this information available to other applications.
この仕様は、PA-TNC属性の新しいセットを定義しています。これらの属性は、ソフトウェアインベントリ情報およびソフトウェアインストール変更イベントの要求を伝達するために使用されます。これらのメッセージの交換により、ソフトウェアインベントリ情報をネットワークエンドポイントアセスメント（NEA）サーバーに送信できるようになり、他のアプリケーションでこの情報を利用できるようになります。
Part of the motivation for the development of SWIMA was to support the IETF's Security Automation and Continuous Monitoring (SACM) architecture. More details about SWIMA's role in SACM appear in Section 7. However, SWIMA has no dependencies on any part of SACM and is usable wherever the NEA architecture is employed.
SWIMAの開発の動機の一部は、IETFのセキュリティ自動化および継続的監視（SACM）アーキテクチャをサポートすることでした。 SACMでのSWIMAの役割の詳細については、セクション7を参照してください。ただし、SWIMAはSACMのどの部分にも依存せず、NEAアーキテクチャが採用されている場所であればどこでも使用できます。
SWIMA defines extensions to the PA-TNC specification [RFC5792]; these extensions are part of the NEA architecture. The NEA specifications define an open solution architecture that enables network operators to collect and utilize information about endpoint configuration and state. This information can be used to enforce policies and monitor endpoint health, among many other activities. Information about the software present on an endpoint is an important consideration for such activities. The new PA-TNC attributes defined in this document are used to communicate software inventory evidence, collected from a range of possible sources, from the Posture Collector on the endpoint to the Posture Validator on a NEA Server using the PA-TNC interface, as shown in Figure 1 below.
SWIMAはPA-TNC仕様[RFC5792]の拡張を定義しています。これらの拡張はNEAアーキテクチャの一部です。 NEA仕様は、ネットワークオペレーターがエンドポイントの構成と状態に関する情報を収集して利用できるようにするオープンソリューションアーキテクチャを定義しています。この情報は、他の多くのアクティビティの中でも、ポリシーを適用し、エンドポイントの状態を監視するために使用できます。エンドポイントに存在するソフトウェアに関する情報は、そのようなアクティビティの重要な考慮事項です。このドキュメントで定義されている新しいPA-TNC属性は、示されているように、PA-TNCインターフェイスを使用して、エンドポイントのポスチャコレクタからNEAサーバーのポスチャバリデータに、さまざまなソースから収集されたソフトウェアインベントリの証拠を伝達するために使用されます。下の図1をご覧ください。
+-------------+ +--------------+
| Posture | <--------PA--------> | Posture |
| Collectors | | Validators |
| (1 .. N) | | (1 .. N) |
+-------------+ +--------------+
| |
| |
| |
+-------------+ +--------------+
| Posture | | Posture |
| Broker | <--------PB--------> | Broker |
| Client | | Server |
+-------------+ +--------------+
| |
| |
+-------------+ +--------------+
| Posture | | Posture |
| Transport | <--------PT--------> | Transport |
| Client | | Server |
| (1 .. N) | | (1 .. N) |
+-------------+ +--------------+
NEA CLIENT NEA SERVER
Figure 1: NEA Reference Model
図1：NEA参照モデル
To better understand this specification, the reader should review the NEA reference architecture as described in "Network Endpoint Assessment (NEA): Overview and Requirements" [RFC5209]. The reader should also review the PA-TNC interfaces as defined in RFC 5792 [RFC5792].
この仕様をよりよく理解するには、「ネットワークエンドポイントアセスメント（NEA）：概要と要件」[RFC5209]で説明されているNEAリファレンスアーキテクチャを確認する必要があります。読者は、RFC 5792 [RFC5792]で定義されているPA-TNCインターフェイスも確認する必要があります。
This document is based on standards published by the Trusted Computing Group's Trusted Network Communications (TNC) workgroup (see <https://trustedcomputinggroup.org/>). The TNC and NEA architectures are interoperable, and many components are equivalent.
このドキュメントは、Trusted Computing GroupのTrusted Network Communications（TNC）ワークグループ（<https://trustedcomputinggroup.org/>を参照）によって公開された標準に基づいています。 TNCおよびNEAアーキテクチャは相互運用可能であり、多くのコンポーネントは同等です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
This section defines terms that have special meaning within this document.
このセクションでは、このドキュメント内で特別な意味を持つ用語を定義します。
o SWIMA-PC - A NEA Posture Collector (PC) that interprets SWIMA attributes sent by SWIMA-PVs and that conforms to this specification. Note that such a Posture Collector might also support other PA-TNC exchanges beyond those defined herein.
o SWIMA-PC-SWIMA-PVから送信されたSWIMA属性を解釈し、この仕様に準拠するNEAポスチャコレクタ（PC）。このようなポスチャコレクタは、ここで定義されているもの以外のPA-TNC交換もサポートしている場合があることに注意してください。
o SWIMA-PV - A NEA Posture Validator (PV) that interprets SWIMA attributes sent by SWIMA-PCs and that conforms to this specification. Note that such a Posture Validator might also support other PA-TNC exchanges beyond those defined herein.
o SWIMA-PV-SWIMA-PCから送信されたSWIMA属性を解釈し、この仕様に準拠するNEA Posture Validator（PV）。このようなポスチャバリデータは、ここで定義されているもの以外のPA-TNC交換もサポートする場合があることに注意してください。
o SWIMA Attribute - A PA-TNC attribute (as defined in RFC 5792 [RFC5792]) whose structure and behavior is defined in this specification.
o SWIMA属性-構造と動作がこの仕様で定義されている（RFC 5792 [RFC5792]で定義されている）PA-TNC属性。
o Endpoint's Software Inventory Evidence Collection - The set of information regarding the set of software installed on an endpoint. An endpoint's Software Inventory Evidence Collection might include information created by or derived from multiple sources, including but not limited to SWID tag files deposited on the filesystem during software installation, information generated by software discovery tools, and information dynamically generated by a software or package management system on an endpoint.
o エンドポイントのソフトウェアインベントリエビデンスコレクション-エンドポイントにインストールされているソフトウェアのセットに関する情報のセット。エンドポイントのソフトウェアインベントリエビデンスコレクションには、ソフトウェアのインストール中にファイルシステムにデポジットされたSWIDタグファイル、ソフトウェアディスカバリツールによって生成された情報、ソフトウェアまたはパッケージ管理によって動的に生成された情報など、複数のソースによって作成または導出された情報が含まれる場合がありますエンドポイント上のシステム。
o Software Inventory Evidence Record - Part of the endpoint's Software Inventory Evidence Collection (which is composed of "records"). Each record corresponds to one installed instance of a particular software product as reported by some data source. It is possible for a single installed instance to have multiple Software Inventory Evidence Records in an endpoint's Software Inventory Evidence Collection -- this can happen if multiple sources all report the same software installation instance.
oソフトウェアインベントリエビデンスレコード-エンドポイントのソフトウェアインベントリエビデンスコレクション（「レコード」で構成される）の一部。各レコードは、いくつかのデータソースから報告された特定のソフトウェア製品の1つのインストール済みインスタンスに対応しています。単一のインストール済みインスタンスがエンドポイントのソフトウェアインベントリエビデンスコレクションに複数のソフトウェアインベントリエビデンスレコードを持つ可能性があります-これは、複数のソースがすべて同じソフトウェアインストールインスタンスを報告している場合に発生する可能性があります。
o Software Identifier - A string associated with a specific version of a specific software product. These identifiers are derived from the records used to describe software products. SWIMA does not limit the formats of these records, nor does it enforce that all data sources populate records using the same format. As such, while each Software Identifier uniquely identifies a specific software product, the same software product might be associated with multiple Software Identifiers reflecting differences between different data sources and supported record formats.
o ソフトウェア識別子-特定のソフトウェア製品の特定のバージョンに関連付けられた文字列。これらの識別子は、ソフトウェア製品を説明するために使用されるレコードから導出されます。 SWIMAはこれらのレコードのフォーマットを制限せず、すべてのデータソースが同じフォーマットを使用してレコードにデータを入力することも強制しません。したがって、各ソフトウェア識別子は特定のソフトウェア製品を一意に識別しますが、同じソフトウェア製品が、異なるデータソースとサポートされているレコード形式の違いを反映する複数のソフトウェア識別子に関連付けられる場合があります。
This section describes the use cases supported by this specification. The primary use of exchanging software inventory information over the PA-TNC interface is to enable a challenger (e.g., a NEA Server) to obtain inventory evidence about some system in a way that conforms to NEA procedures. Collected software information can support a range of security activities, including determining whether an endpoint is permitted to connect to the enterprise, determining which endpoints contain software that requires patching, and similar activities.
このセクションでは、この仕様でサポートされる使用例について説明します。 PA-TNCインターフェイスを介してソフトウェアインベントリ情報を交換する主な用途は、チャレンジャー（NEAサーバーなど）が、NEA手順に準拠した方法で、システムに関するインベントリの証拠を取得できるようにすることです。収集されたソフトウェア情報は、エンドポイントが企業への接続を許可されているかどうかの判断、パッチ適用を必要とするソフトウェアが含まれているエンドポイントの判断など、さまざまなセキュリティアクティビティをサポートできます。
Some enterprises might define security policies that require connected endpoints to have certain pieces of security software installed. By contrast, some security policies might prevent access to resources by endpoints that have certain prohibited pieces of software installed, since such applications might pose a security risk. To support such policies, the NEA Server needs to collect software inventory evidence from a target endpoint that is seeking to initiate or continue connectivity to the enterprise resource.
企業によっては、接続されたエンドポイントに特定のセキュリティソフトウェアをインストールすることを要求するセキュリティポリシーを定義している場合があります。対照的に、一部のセキュリティポリシーでは、特定の禁止されたソフトウェアがインストールされているエンドポイントによるリソースへのアクセスを妨げる場合があります。これは、そのようなアプリケーションがセキュリティリスクをもたらす可能性があるためです。このようなポリシーをサポートするには、NEAサーバーは、エンタープライズリソースへの接続を開始または継続しようとしているターゲットエンドポイントからソフトウェアインベントリの証拠を収集する必要があります。
Based on this specification, the SWIMA-PC can provide a complete or partial inventory to the SWIMA-PV as required to determine policy compliance. The SWIMA-PV can then use this as evidence of compliance or non-compliance to make a policy-based access decision.
この仕様に基づいて、SWIMA-PCは、必要に応じて完全または部分的なインベントリをSWIMA-PVに提供し、ポリシーのコンプライアンスを決定できます。 SWIMA-PVは、これをコンプライアンスまたは非コンプライアンスの証拠として使用して、ポリシーベースのアクセス決定を行うことができます。
Many tools use information about an endpoint's software inventory to monitor and enforce the security of a network. For example, a software-patching tool needs to determine if there is out-of-date software installed that needs to be updated. A vulnerability management tool needs to identify endpoints with known vulnerable software installed (patched or otherwise) to gauge an endpoint's relative exposure to attack. A license management tool needs to verify that all installed software within the enterprise is accounted for. A central repository representing an up-to-date understanding of each endpoint's software inventory facilitates these activities. Multiple tools can share such a repository, ensuring that software inventory information is collected more frequently and efficiently, leading to a more complete and consistent understanding of installed software state as compared to each tool collecting the same inventory information from endpoints individually.
多くのツールは、エンドポイントのソフトウェアインベントリに関する情報を使用して、ネットワークのセキュリティを監視および実施します。たとえば、ソフトウェアパッチツールは、更新が必要な古いソフトウェアがインストールされているかどうかを判断する必要があります。脆弱性管理ツールは、既知の脆弱なソフトウェアがインストールされている（パッチが適用されているなどの）エンドポイントを識別して、エンドポイントの攻撃への相対的な露出を測定する必要があります。ライセンス管理ツールは、企業内にインストールされたすべてのソフトウェアが説明されていることを確認する必要があります。各エンドポイントのソフトウェアインベントリの最新の理解を表す中央リポジトリは、これらのアクティビティを容易にします。複数のツールがこのようなリポジトリを共有できるため、ソフトウェアインベントリ情報がより頻繁かつ効率的に収集され、各ツールがエンドポイントから個別に同じインベントリ情報を収集するよりも、インストールされたソフトウェアの状態をより完全かつ一貫して理解できます。
This specification supports these activities through a number of mechanisms. As noted above, a SWIMA-PC can provide a complete list of software present in an endpoint's Software Inventory Evidence Collection to the SWIMA-PV, which can then pass this information on to a central repository, such as a Configuration Management Database (CMDB) or similar application. In addition, SWIMA-PCs are required to be able to monitor for changes to an endpoint's Software Inventory Evidence Collection in near real time and can be requested to immediately push reports of detected changes to the SWIMA-PV. Thus, any central repository fed by a SWIMA-PV receiving inventory information can be updated quickly after a change occurs. Keeping a central repository synchronized with current software inventory information in this way allows tools to make efficient decisions based on up-to-date, consistent information.
この仕様は、いくつかのメカニズムを通じてこれらのアクティビティをサポートします。上記のように、SWIMA-PCはエンドポイントのソフトウェアインベントリエビデンスコレクションに存在するソフトウェアの完全なリストをSWIMA-PVに提供でき、SWIMA-PVはこの情報を構成管理データベース（CMDB）などの中央リポジトリに渡すことができます。または同様のアプリケーション。さらに、SWIMA-PCは、エンドポイントのソフトウェアインベントリエビデンスコレクションへの変更をほぼリアルタイムで監視できる必要があり、検出された変更のレポートをSWIMA-PVにすぐにプッシュするように要求できます。したがって、インベントリ情報を受信するSWIMA-PVによって供給される中央リポジトリは、変更が発生した後すぐに更新できます。この方法で中央リポジトリを現在のソフトウェアインベントリ情報と同期させることにより、ツールは最新の一貫した情報に基づいて効率的な決定を行うことができます。
SWIMA is intended to operate over the PA-TNC interface and, as such, is intended to meet the use cases set out in the PA-TNC specification.
SWIMAはPA-TNCインターフェース上で動作することを目的としており、したがって、PA-TNC仕様で定められた使用例に適合することを目的としています。
Some use cases not covered by this specification include:
この仕様でカバーされていないいくつかのユースケースは次のとおりです。
o Addressing how the endpoint's Software Inventory Evidence Collection is populated. In particular, NEA components are not expected to perform software discovery activities beyond compiling information in an endpoint's Software Inventory Evidence Collection. This collection might come from multiple sources on the endpoint (e.g., information generated dynamically by package management tools or discovery tools, as well as SWID tag files discovered on the filesystem). While an enterprise might make use of software discovery capabilities to identify installed software, such capabilities are outside the scope of this specification.
oエンドポイントのソフトウェアインベントリエビデンスコレクションへの入力方法について説明します。特に、NEAコンポーネントは、エンドポイントのソフトウェアインベントリエビデンスコレクションの情報をコンパイルする以上のソフトウェア検出アクティビティを実行することは期待されていません。このコレクションは、エンドポイントの複数のソース（パッケージ管理ツールや検出ツールによって動的に生成された情報、ファイルシステムで検出されたSWIDタグファイルなど）から取得される場合があります。企業はソフトウェアの検出機能を使用してインストールされたソフトウェアを特定する場合がありますが、そのような機能はこの仕様の範囲外です。
o Converting inventory information expressed in a proprietary format into formats used in the attributes described in this specification. Instead, this specification focuses exclusively on defining interfaces for the transportation of software information, expecting that reporting tools will converge around some set of standardized formats for this information.
o 独自の形式で表現された在庫情報を、この仕様で説明されている属性で使用される形式に変換します。代わりに、この仕様は、ソフトウェア情報の転送のためのインターフェースの定義にのみ焦点を当てており、レポートツールがこの情報の標準化されたフォーマットのセットに集中することを期待しています。
o Mechanisms for a Posture Validator to request a specific list of software information based on arbitrary software properties. For example, requesting only information about software from a particular vendor is not supported. After the endpoint's Software Inventory Evidence Collection has been copied to some central location, such as the CMDB, processes there can perform queries based on any criteria present in the collected information, but this specification does not address using such queries to constrain the initial collection of this information from the endpoint.
o Posture Validatorが任意のソフトウェアプロパティに基づいてソフトウェア情報の特定のリストを要求するためのメカニズム。たとえば、特定のベンダーからのソフトウェアに関する情報のみを要求することはサポートされていません。エンドポイントのソフトウェアインベントリエビデンスコレクションがCMDBなどの中央の場所にコピーされた後、プロセスは収集された情報に存在する任意の基準に基づいてクエリを実行できますが、この仕様では、そのようなクエリを使用してエンドポイントからのこの情報。
o Use of properties of certain sources of software information that might facilitate local tests (i.e., on the endpoint) of endpoint state. For example, the optional package_footprint field of an ISO SWID tag can contain a list of files and hash values associated with the software indicated by the tag. Tools on the endpoint can use the values in this field to test for the presence of the indicated files. Successful evaluation of such tests leads to greater assurance that the indicated software is present on the endpoint. Currently, most SWID tag creators do not provide values for tag fields that support local testing. For this reason, the added complexity of supporting endpoint testing using these fields is out of scope for this specification, but this topic may be considered in a future version.
o エンドポイント状態のローカルテスト（つまり、エンドポイント上）を容易にする可能性があるソフトウェア情報の特定のソースのプロパティの使用。たとえば、ISO SWIDタグのオプションのpackage_footprintフィールドには、タグで示されるソフトウェアに関連付けられたファイルとハッシュ値のリストを含めることができます。エンドポイント上のツールは、このフィールドの値を使用して、指定されたファイルの存在をテストできます。このようなテストの評価が成功すると、示されたソフトウェアがエンドポイントに存在することがより確実になります。現在、ほとんどのSWIDタグ作成者は、ローカルテストをサポートするタグフィールドの値を提供していません。このため、これらのフィールドを使用したエンドポイントテストのサポートの追加の複雑さは、この仕様の範囲外ですが、このトピックは将来のバージョンで検討される可能性があります。
Below are the requirements that SWIMA must meet in order to successfully play its role in the NEA architecture.
SWIMAがNEAアーキテクチャで役割を果たすために必要な要件は次のとおりです。
Efficient: The NEA architecture enables delay of network access until the endpoint is determined not to pose a security threat to the network, based on its asserted integrity information. To minimize user frustration, SWIMA ought to minimize overhead delays and make PA-TNC communications as rapid and efficient as possible.
効率的：NEAアーキテクチャは、アサートされた整合性情報に基づいて、エンドポイントがネットワークにセキュリティ脅威をもたらさないと判断されるまで、ネットワークアクセスの遅延を可能にします。ユーザーの不満を最小限に抑えるために、SWIMAはオーバーヘッドの遅延を最小限に抑え、PA-TNC通信を可能な限り迅速かつ効率的にする必要があります。
Scalable: SWIMA needs to be usable in enterprises that contain tens of thousands of endpoints or more. As such, it needs to allow security tools to make decisions based on up-to-date information about an endpoint's software inventory without creating an excessive burden on the enterprise's network.
スケーラブル：SWIMAは、数万以上のエンドポイントを含む企業で使用できる必要があります。そのため、企業のネットワークに過度の負担をかけることなく、セキュリティツールがエンドポイントのソフトウェアインベントリに関する最新の情報に基づいて決定できるようにする必要があります。
Support precise and complete historical reporting: This specification outlines capabilities that support real-time understanding of the state of endpoints in a network in a way that can be used by other tools. One means of facilitating such an outcome is for a CMDB to be able to contain information about all endpoints connected to the enterprise for all points in time between the endpoint's first connection and the present. In such a scenario, it is necessary that any SWIMA-PC be able to report any changes to its Software Inventory Evidence Collection in near real time while connected and, upon reconnection to the enterprise, be able to update the NEA Server (and, through it, the CMDB) with regard to the state of its Software Inventory Evidence Collection throughout the entire interval when it was not connected.
正確で完全な履歴レポートのサポート：この仕様は、他のツールで使用できる方法でネットワーク内のエンドポイントの状態をリアルタイムで理解することをサポートする機能の概要を示しています。そのような結果を容易にする1つの方法は、エンドポイントの最初の接続と現在の間のすべての時点について、企業に接続されたすべてのエンドポイントに関する情報をCMDBに含めることができるようにすることです。このようなシナリオでは、SWIMA-PCがソフトウェアインベントリエビデンスコレクションへの変更をほぼリアルタイムで接続中に報告でき、企業に再接続すると、NEAサーバーを更新できる必要があります。接続されていない期間全体を通して、ソフトウェアインベントリエビデンスコレクションの状態に関してCMDBに通知します。
There are certain capabilities that users of SWIMA might require but that are beyond the scope of SWIMA itself and need to be addressed by other standards.
SWIMAのユーザーが必要とする特定の機能がありますが、SWIMA自体の範囲を超えており、他の標準で対処する必要があります。
Confidentiality: SWIMA does not define a mechanism for confidentiality, nor is confidentiality automatically provided by using the PA-TNC interface. In the NEA architecture, confidentiality is generally provided by the underlying transport protocols, such as the PT binding to TLS [RFC6876] or PT-EAP (Posture Transport for Tunneled Extensible Authentication Protocol (EAP) Methods) [RFC7171]; see Section 7 for more information on related standards. The information conveyed by SWIMA is often sensitive in nature for both security (Section 8) and privacy (Section 9) reasons. Those who implement SWIMA need to ensure that appropriate NEA transport mechanisms are employed to meet confidentiality requirements.
機密性：SWIMAは機密性のメカニズムを定義していません。また、PA-TNCインターフェイスを使用して機密性が自動的に提供されることもありません。 NEAアーキテクチャでは、機密性は通常、TLSへのPTバインディング[RFC6876]やPT-EAP（トンネル拡張認証プロトコル（EAP）メソッドのポスチャトランスポート）[RFC7171]などの基になるトランスポートプロトコルによって提供されます。関連規格の詳細については、セクション7を参照してください。 SWIMAによって伝達される情報は、セキュリティ（セクション8）とプライバシー（セクション9）の両方の理由から、本質的に機密であることがよくあります。 SWIMAを実装する人は、機密性要件を満たすために適切なNEAトランスポートメカニズムが採用されていることを確認する必要があります。
The Posture Broker Client and Posture Broker Server are assumed to provide reliable delivery for PA-TNC messages and attributes sent between the SWIMA-PCs and the SWIMA-PVs. "Reliable delivery" means that either a message is delivered or the sender is made aware of the delivery failure. In the event that reliable delivery cannot be provided, some SWIMA features, primarily subscriptions, might not behave as expected.
Posture Broker ClientおよびPosture Broker Serverは、SWIMA-PCとSWIMA-PVの間で送信されるPA-TNCメッセージおよび属性の信頼できる配信を提供すると想定されています。 「信頼できる配信」とは、メッセージが配信されるか、送信者に配信の失敗が通知されることを意味します。信頼性の高い配信を提供できない場合、一部のSWIMA機能（主にサブスクリプション）が期待どおりに動作しない可能性があります。
This specification explicitly does not assume that software inventory information exchanges reflect the software installation state of the endpoint. This specification does not attempt to detect when the endpoint is providing false information, either through malice or error, but instead focuses on correctly and reliably providing the reported Software Inventory Evidence Collection to the NEA Server. Tools that employ the SWIMA standard can include methods to help verify the accuracy of reports, but how those tools do so is beyond the scope of this specification.
この仕様は、ソフトウェアインベントリ情報の交換がエンドポイントのソフトウェアインストール状態を反映することを明示的に想定していません。この仕様は、悪意やエラーによってエンドポイントが誤った情報を提供していることを検出しようとするのではなく、報告されたソフトウェアインベントリエビデンスコレクションをNEAサーバーに正しく確実に提供することに焦点を当てています。 SWIMA標準を使用するツールには、レポートの正確性を検証するのに役立つ方法を含めることができますが、それらのツールがどのように行うかは、この仕様の範囲外です。
Similarly, this specification makes no assumption about the completeness of the Software Inventory Evidence Collection's coverage of the total set of software installed on the endpoint. It is possible, and even likely, that some installed software is not represented by a record in an endpoint's Software Inventory Evidence Collection. Instead, SWIMA ensures that what does get reported is reported consistently and that the software products that are reported can be reliably tracked.
同様に、この仕様は、ソフトウェアインベントリエビデンスコレクションがエンドポイントにインストールされているソフトウェアのセット全体を網羅していることを想定していません。インストールされている一部のソフトウェアが、エンドポイントのソフトウェアインベントリエビデンスコレクションのレコードで表されていない可能性があります。代わりに、SWIMAは、報告された内容が一貫して報告され、報告されたソフトウェア製品を確実に追跡できるようにします。
See Section 8 for more on this security consideration.
このセキュリティの考慮事項の詳細については、セクション8を参照してください。
SWIMA facilitates the exchange of software inventory and event information. Specifically, each application supporting SWIMA includes a component known as the SWIMA-PC that receives SWIMA attributes. The SWIMA-PC is also responsible for sending appropriate SWIMA attributes back to the SWIMA-PV in response. This section outlines what software inventories and events are and the requirements on SWIMA-PCs and SWIMA-PVs in order to support the stated use cases of this specification.
SWIMAは、ソフトウェアインベントリとイベント情報の交換を容易にします。具体的には、SWIMAをサポートする各アプリケーションには、SWIMA属性を受け取るSWIMA-PCと呼ばれるコンポーネントが含まれています。 SWIMA-PCは、応答として適切なSWIMA属性をSWIMA-PVに送り返す役割も果たします。このセクションでは、この仕様の規定された使用例をサポートするためのSWIMA-PCとSWIMA-PVのソフトウェアインベントリとイベントの概要について説明します。
The records in an endpoint's Software Inventory Evidence Collection come from one or more "sources". A source represents one collection of software inventory information about the endpoint. Examples of sources include, but are not limited to, ISO SWID tags deposited on the filesystem and collected therefrom, information derived from package managers, and the output of software inventory-scanning tools.
エンドポイントのソフトウェアインベントリエビデンスコレクションのレコードは、1つ以上の「ソース」からのものです。ソースは、エンドポイントに関するソフトウェアインベントリ情報の1つのコレクションを表します。ソースの例には、ファイルシステムにデポジットされてそこから収集されたISO SWIDタグ、パッケージマネージャーから得られた情報、およびソフトウェアインベントリスキャンツールの出力が含まれますが、これらに限定されません。
There is no expectation that any one source of inventory information will have either perfect or complete software inventory information. For this reason, this specification supports the simultaneous use of multiple sources of software inventory information. Each source might have its own "sphere of expertise" and report the software within that sphere. For example, a package manager would have an excellent understanding of the software that it managed but would not necessarily have any information about software installed via other means.
インベントリ情報の1つのソースが完全または完全なソフトウェアインベントリ情報を持つことは期待されていません。このため、この仕様は、ソフトウェアインベントリ情報の複数のソースの同時使用をサポートしています。各ソースには独自の「専門知識の範囲」があり、その範囲内のソフトウェアを報告する場合があります。たとえば、パッケージマネージャーは、管理するソフトウェアをよく理解していますが、必ずしも他の方法でインストールされたソフトウェアに関する情報を持っているとは限りません。
A SWIMA-PC is not required to utilize every possible source of software information on its endpoint. Some SWIMA-PCs might be explicitly tied only to one or a handful of software inventory sources, or a given SWIMA-PC could be designed to dynamically accommodate new sources. For all software inventory evidence sources that a particular SWIMA-PC supports, it MUST completely support all requirements of this specification with regard to those sources. A potential source that cannot support some set of required functionality (e.g., it is unable to monitor the software it reports for change events, as discussed in Section 3.6) MUST NOT be used as a source of endpoint software inventory information, even if it could provide some information. In other words, a source either supports full functionality as described in this specification or cannot be used at all. In the event that a previously used source becomes unavailable, this would be treated as a discontinuity in the SWIMA-PC's reporting. Section 3.7.1 describes how to use changes in the Event Identifier (EID) Epoch value to indicate a reporting discontinuity.
SWIMA-PCは、エンドポイントでソフトウェア情報の考えられるすべてのソースを利用する必要はありません。一部のSWIMA-PCは、1つまたは少数のソフトウェアインベントリソースのみに明示的に関連付けられている場合や、特定のSWIMA-PCが新しいソースに動的に対応するように設計されている場合があります。特定のSWIMA-PCがサポートするすべてのソフトウェアインベントリ証拠ソースについては、それらのソースに関するこの仕様のすべての要件を完全にサポートする必要があります。必要な機能の一部をサポートできない潜在的なソース（たとえば、セクション3.6で説明されているように、変更イベントについてレポートするソフトウェアを監視できない）は、エンドポイントソフトウェアのインベントリ情報のソースとして使用できませんいくつかの情報を提供します。つまり、ソースは、この仕様で説明されているように完全な機能をサポートするか、まったく使用できません。以前に使用されたソースが利用できなくなった場合、これはSWIMA-PCのレポートで不連続として扱われます。セクション3.7.1では、イベントID（EID）エポック値の変更を使用して、レポートの不連続性を示す方法について説明します。
When sending information about installed software, the SWIMA-PC MUST include the complete set of relevant data from all supported sources of software inventory evidence. In other words, sources need to be used consistently. This is because if a particular source is included in an initial inventory but excluded from a later inventory, the SWIMA-PV receiving this information might reasonably conclude that the software reported by that source was no longer installed on the endpoint. As such, it is important that all supported sources be used every time the SWIMA-PC provides information to a SWIMA-PV.
インストールされたソフトウェアに関する情報を送信する場合、SWIMA-PCは、ソフトウェアインベントリ証拠のサポートされているすべてのソースからの関連データの完全なセットを含める必要があります。つまり、ソースは一貫して使用する必要があります。これは、特定のソースが初期インベントリに含まれているが、後のインベントリから除外されている場合、この情報を受信するSWIMA-PVは、そのソースによって報告されたソフトウェアがエンドポイントにインストールされなくなったと合理的に結論付ける可能性があるためです。そのため、SWIMA-PCがSWIMA-PVに情報を提供するたびに、サポートされているすべてのソースを使用することが重要です。
Note that if a SWIMA-PC collects data from multiple sources, it is possible that some software products might be "double counted". This can happen if two or more sources of inventory evidence provide a record for a single installation of a software product. When a SWIMA-PC reports information or records events from multiple inventory evidence sources, it MUST use the information those sources provide, rather than attempt to perform some form of reduction. In other words, if multiple sources report records corresponding to a single installation of a software product, all such records from each source are required to be part of the SWIMA-PC's processing even if this might lead to multiple reporting, and the SWIMA-PC is not to ignore some records to avoid such multiple reporting.
SWIMA-PCが複数のソースからデータを収集する場合、一部のソフトウェア製品が「ダブルカウント」される可能性があることに注意してください。これは、インベントリ証拠の2つ以上のソースがソフトウェア製品の単一インストールの記録を提供する場合に発生する可能性があります。 SWIMA-PCが情報を報告したり、複数のインベントリエビデンスソースからイベントを記録したりするときは、何らかの形で削減を試みるのではなく、それらのソースが提供する情報を使用する必要があります。言い換えると、ソフトウェア製品の単一のインストールに対応するレコードが複数のソースから報告される場合、複数のレポートにつながる可能性があるとしても、各ソースからのそのようなすべてのレコードはSWIMA-PCの処理の一部である必要があります。SWIMA-PCこのような複数のレポートを回避するために一部のレコードを無視しないことです。
All inventory records reported by a SWIMA-PC include a Source Identifier linking them to a particular source. Source Identifiers are discussed more in Section 3.4.5. As discussed in that section, Source Identifiers can help consumers of SWIMA data identify cases of multiple reporting.
SWIMA-PCによって報告されるすべてのインベントリレコードには、特定のソースにリンクするソース識別子が含まれています。ソース識別子については、3.4.5項で詳しく説明します。そのセクションで説明したように、ソース識別子は、SWIMAデータの利用者が複数のレポートのケースを識別するのに役立ちます。
SWIMA conveys records about software presence from a SWIMA-PC to a SWIMA-PV. SWIMA does not manage the actual generation or collection of such records on the endpoint. As a result, information available to SWIMA-PCs might come in a variety of formats, and a SWIMA-PC could have little control over the format of the data made available to it. Because of this, SWIMA places no constraints on the format of these generated records and supports an open set of record formats by which installed software instances can be described. The following terms are used in this document:
SWIMAは、SWIMA-PCからSWIMA-PVにソフトウェアの存在に関するレコードを伝達します。 SWIMAは、エンドポイントでのそのようなレコードの実際の生成または収集を管理しません。その結果、SWIMA-PCで利用可能な情報はさまざまな形式で提供される可能性があり、SWIMA-PCは、利用可能なデータの形式をほとんど制御できません。このため、SWIMAはこれらの生成されたレコードのフォーマットに制約を課すことはなく、インストールされているソフトウェアインスタンスを記述できるレコードフォーマットのオープンセットをサポートしています。このドキュメントでは、次の用語が使用されています。
o Data model - The format used to structure data within a given record. SWIMA does not constrain the data models it conveys.
o データモデル-特定のレコード内のデータを構造化するために使用される形式。 SWIMAは、伝達するデータモデルを制約しません。
o Record - A populated instance of some data model that describes a software product.
o レコード-ソフトウェア製品を説明するデータモデルの入力済みインスタンス。
Do not confuse the "data model" described here with the structure of the SWIMA messages and attributes used to convey information between SWIMA-PVs and SWIMA-PCs. The SWIMA standard dictates the structure of its messages and attributes. Some attributes, however, have specific fields used to convey inventory records, and those fields support an extensible list of data models for their values. In other words, SWIMA data models provide an extension point within SWIMA attributes that allows the structure of inventory records to evolve.
ここで説明する「データモデル」を、SWIMA-PVとSWIMA-PCの間で情報を伝達するために使用されるSWIMAメッセージと属性の構造と混同しないでください。 SWIMA標準は、そのメッセージと属性の構造を規定しています。ただし、一部の属性には、在庫レコードを伝達するために使用される特定のフィールドがあり、それらのフィールドは、値のデータモデルの拡張可能なリストをサポートしています。つまり、SWIMAデータモデルは、SWIMA属性内に拡張ポイントを提供し、在庫レコードの構造を進化させることができます。
The data model used to structure software inventory information has very little impact on the behavior of the components defined in this specification. The SWIMA-PV has no dependency on the data model of records conveyed in SWIMA messages. For this reason, it MUST NOT reject a message or respond with a PA-TNC Error due to the data model used to structure records in attributes it receives. Similarly, it MUST NOT reject a message or respond with a PA-TNC Error if a record fails to comply with a stated format, unless that failure prevents correct parsing of the attribute itself. In short, the record bodies are effectively treated as "black boxes" by the SWIMA-PV. (Note that the SWIMA-PV might serve as the "front end" of other functionality that does have a dependency on the data model used to structure software information, but any such dependency is beyond the scope of this specification and needs to be addressed outside the behaviors specified in this document. This specification is only concerned with the collection and delivery of software inventory information; components that consume and use this information are a separate concern.)
ソフトウェアインベントリ情報の構造化に使用されるデータモデルは、この仕様で定義されているコンポーネントの動作にほとんど影響を与えません。 SWIMA-PVは、SWIMAメッセージで伝達されるレコードのデータモデルに依存しません。このため、受信する属性のレコードを構造化するために使用されるデータモデルが原因で、メッセージを拒否したり、PA-TNCエラーで応答してはなりません（MUST NOT）。同様に、もしその失敗が属性自体の正しい解析を妨げない限り、それがメッセージを拒否したり、レコードが規定のフォーマットに準拠しなかった場合、PA-TNCエラーで応答してはなりません（MUST NOT）。つまり、レコード本体はSWIMA-PVによって「ブラックボックス」として効果的に扱われます。 （SWIMA-PVは、ソフトウェア情報の構造化に使用されるデータモデルに依存する他の機能の「フロントエンド」として機能する場合がありますが、そのような依存関係はこの仕様の範囲を超えているため、外部で対処する必要があります。このドキュメントで指定されている動作。この仕様は、ソフトウェアインベントリ情報の収集と配信にのみ関係します。この情報を使用および使用するコンポーネントは別の問題です。）
The SWIMA-PC does have one functional dependency on the data models used in the software records it delivers, but only insofar as it is required to deterministically create a Software Identifier (described in Section 3.4.1) based on each record it delivers. The SWIMA-PC MUST be able to generate a Software Identifier for each record it delivers, and if the SWIMA-PC cannot do so, it cannot deliver the record. All SWIMA-PCs MUST at least be able to generate Software Identifiers for the data model types specified in Section 6 of this document. A SWIMA-PC MAY include the ability to generate Software Identifiers for other data model types and thus be able to support them as well.
SWIMA-PCは、提供するソフトウェアレコードで使用されるデータモデルに1つの機能的な依存関係がありますが、提供する各レコードに基づいてソフトウェア識別子（セクション3.4.1で説明）を確定的に作成する必要がある場合に限ります。 SWIMA-PCは、配信するレコードごとにソフトウェア識別子を生成できなければなりません。SWIMA-PCが生成できない場合、レコードを配信できません。すべてのSWIMA-PCは、少なくともこのドキュメントのセクション6で指定されたデータモデルタイプのソフトウェア識別子を生成できる必要があります。 SWIMA-PCには、他のデータモデルタイプのソフトウェア識別子を生成する機能が含まれている可能性があるため、それらをサポートすることもできます。
In the most basic exchange supported by this specification, a SWIMA-PV sends a request to the SWIMA-PC, requesting some type of information about the endpoint's software inventory. This simple exchange is shown in Figure 2.
この仕様でサポートされる最も基本的な交換では、SWIMA-PVが要求をSWIMA-PCに送信し、エンドポイントのソフトウェアインベントリに関するある種の情報を要求します。この単純な交換を図2に示します。
+-------------+ +--------------+
| SWIMA-PC | | SWIMA-PV | Time
+-------------+ +--------------+ |
| | |
|<------------SWIMA Request---------------| |
| | |
|-------------SWIMA Response------------->| |
| | V
Figure 2: Basic SWIMA Attribute Exchange
図2：基本的なSWIMA属性交換
Upon receiving such a SWIMA Request from the SWIMA-PV, the SWIMA-PC is expected to collect all the relevant software inventory information from the endpoint's Software Inventory Evidence Collection and place it within its response attribute.
SWIMA-PVからこのようなSWIMA要求を受信すると、SWIMA-PCは、エンドポイントのソフトウェアインベントリエビデンスコレクションから関連するすべてのソフトウェアインベントリ情報を収集し、その応答属性内に配置することが期待されます。
SWIMA-PVs MUST discard, without error, any SWIMA Response attributes that they receive for which they do not know the SWIMA Request parameters that led to this SWIMA Response. This is due to the fact that the SWIMA Request includes parameters that control the nature of the response (as will be described in the following sections); without knowing those parameters, the SWIMA Response cannot be reliably interpreted. Each SWIMA Request includes a Request ID, which is echoed in any SWIMA Response to that request and allows matching of responses to requests. See Section 5.5 for more on Request IDs. Receiving an unsolicited SWIMA Response attribute will most often happen when a NEA Server has multiple SWIMA-PVs; one SWIMA-PV sends a SWIMA Request, but unless exclusive delivery [RFC5793] is set by the sender and honored by the recipient, multiple SWIMA-PVs will receive copies of the resulting SWIMA Response. In this case, the SWIMA-PV that didn't send the SWIMA Request would lack the context necessary to correctly interpret the SWIMA Response it received and would simply discard it. Note, however, that proprietary measures might allow a SWIMA-PV to discover the SWIMA Request parameters for a SWIMA Response even if that SWIMA-PV did not send the given SWIMA Request. As such, there is no blanket requirement for a SWIMA-PV to discard all SWIMA Responses to SWIMA Requests that the SWIMA-PV did not generate itself -- only that SWIMA-PVs are required to discard SWIMA Responses for which they cannot get the necessary context to interpret.
SWIMA-PVは、このSWIMA応答の原因となったSWIMAリクエストパラメータを知らない、受信したSWIMA応答属性をエラーなく破棄する必要があります。これは、SWIMAリクエストに応答の性質を制御するパラメーターが含まれているためです（次のセクションで説明します）。これらのパラメーターを知らないと、SWIMA応答を確実に解釈できません。各SWIMA要求には要求IDが含まれています。これは、その要求に対するSWIMA応答にエコーされ、要求への応答の照合を可能にします。リクエストIDの詳細については、セクション5.5を参照してください。非送信請求SWIMA応答属性の受信は、NEAサーバーに複数のSWIMA-PVがある場合に最も頻繁に発生します。 1つのSWIMA-PVがSWIMAリクエストを送信しますが、送信者が排他配信[RFC5793]を設定し、受信者がそれを尊重しない限り、複数のSWIMA-PVが結果のSWIMA応答のコピーを受信します。この場合、SWIMA要求を送信しなかったSWIMA-PVは、受信したSWIMA応答を正しく解釈するために必要なコンテキストを欠き、単に破棄します。ただし、独自の対策により、SWIMA-PVが特定のSWIMA要求を送信しなかった場合でも、SWIMA-PVがSWIMA応答のSWIMA要求パラメータを検出できる場合があることに注意してください。そのため、SWIMA-PVがそれ自体で生成しなかったSWIMA要求に対するすべてのSWIMA応答を破棄するためのSWIMA-PVの包括的な要件はありません。SWIMA-PVは、必要なSWIMA応答を破棄するために必要です。解釈するコンテキスト。
In the case that it is possible to do so, the SWIMA-PC SHOULD send its SWIMA Response attribute to the SWIMA-PV that requested it, using exclusive delivery as described in Section 4.5 of "PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC)" [RFC5793]. Exclusive delivery requests that only the sender of the SWIMA Request be the receiver of the resulting SWIMA Response. Note, however, that PB-TNC does not require the recipient to honor the exclusive delivery flag in messages that it receives, so setting the flag cannot be guaranteed to prevent a SWIMA-PV from receiving unsolicited SWIMA Responses.
それが可能である場合、SWIMA-PCは、「PB-TNC：A Posture Broker（PB）」のセクション4.5で説明されているように、排他配信を使用して、SWIMA応答属性を要求したSWIMA-PVに送信する必要があります（SHOULD）。 Trusted Network Connect（TNC）と互換性のあるプロトコル」[RFC5793]。 SWIMA要求の送信者のみが結果のSWIMA応答の受信者になることを排他配信要求。ただし、PB-TNCは受信者が受信したメッセージの排他配信フラグを受け入れる必要がないため、フラグを設定してもSWIMA-PVが一方的なSWIMA応答を受信するのを防ぐことはできません。
Note that, in the case that a single endpoint hosts multiple SWIMA-PCs, a single SWIMA Request could result in multiple SWIMA Responses. SWIMA-PVs need to handle such an occurrence without error.
単一のエンドポイントが複数のSWIMA-PCをホストしている場合、単一のSWIMA要求が複数のSWIMA応答になる可能性があることに注意してください。 SWIMA-PVは、このような事態をエラーなしで処理する必要があります。
All numeric values sent in SWIMA messages are sent in network (big endian) byte order.
SWIMAメッセージで送信されるすべての数値は、ネットワーク（ビッグエンディアン）バイトオーダーで送信されます。
Different parameters in the SWIMA Request can influence what information is returned in the SWIMA Response. However, while each SWIMA Response provides different additional information about this installed software, the responses all share a common set of fields that support reliable software identification on an endpoint. These fields include Software Identifiers, Data Model Type, Record Identifiers, Software Locators, and Source Identifiers. These fields are present for each reported piece of software in each type of SWIMA Response. The following sections examine these information types in more detail.
SWIMAリクエストのさまざまなパラメータが、SWIMAレスポンスで返される情報に影響を与える可能性があります。ただし、各SWIMA応答はこのインストールされたソフトウェアに関するさまざまな追加情報を提供しますが、応答はすべて、エンドポイントで信頼できるソフトウェア識別をサポートする共通のフィールドセットを共有します。これらのフィールドには、ソフトウェア識別子、データモデルタイプ、レコード識別子、ソフトウェアロケーター、およびソース識別子が含まれます。これらのフィールドは、SWIMA応答の各タイプで報告されたソフトウェアごとに表示されます。以下のセクションでは、これらの情報タイプについて詳しく説明します。
A Software Identifier uniquely identifies a specific version of a specific software product. The SWIMA standard does not dictate the structure of a Software Identifier (beyond stating that it is a string) or define how it is created. Instead, each data model described in the "Software Data Model Types" registry (Section 10.5) includes its own rules for how a Software Identifier is created based on a record in the endpoint's Software Inventory Evidence Collection expressed in that data model. Other data models will have their own procedures for the creation of associated Software Identifiers. Within SWIMA, the Software Identifier is simply an opaque string, and there is never any need to unpack any information that might be part of that identifier.
ソフトウェア識別子は、特定のソフトウェア製品の特定のバージョンを一意に識別します。 SWIMA標準は、ソフトウェアIDの構造（文字列であることを示す以外に）を規定したり、ソフトウェアIDの作成方法を定義したりしていません。代わりに、「ソフトウェアデータモデルタイプ」レジストリ（セクション10.5）で説明されている各データモデルには、そのデータモデルで表現されたエンドポイントのソフトウェアインベントリエビデンスコレクションのレコードに基づいてソフトウェア識別子を作成する方法に関する独自のルールが含まれています。他のデータモデルには、関連するソフトウェア識別子を作成するための独自の手順があります。 SWIMA内では、ソフトウェア識別子は単に不透明な文字列であり、その識別子の一部である可能性がある情報をアンパックする必要は決してありません。
A Software Identifier is a fraction of the size of the inventory record from which it is derived. For this reason, it is often more efficient to collect full inventories using Software Identifiers and only collect full records when necessary using targeted requests. For some combinations of data models and sources, the full record might never be necessary, as the identifier can be directly correlated to the contents of the full record. This is possible with authoritative SWID tags, since these tags always have the same contents and thus a Software Identifier derived from these tags can be used as a lookup to a local copy of the full tag. For other combinations of source and data model, a server might not be able to determine the specific software product and version associated with the identifier without requesting the delivery of the full record. However, even in those cases, downstream consumers of this information might never need the full record as long as the Software Identifiers they receive can be tracked reliably. A SWIMA-PV can use Software Identifiers to track the presence of specific software products on an endpoint over time in a bandwidth-efficient manner.
ソフトウェア識別子は、それが導出されたインベントリレコードのサイズの一部です。このため、多くの場合、ソフトウェア識別子を使用して完全なインベントリを収集し、対象のリクエストを使用して必要な場合にのみ完全なレコードを収集する方が効率的です。データモデルとソースの組み合わせによっては、識別子を完全なレコードの内容に直接関連付けることができるため、完全なレコードが必要になることはありません。これは、信頼できるSWIDタグで可能です。これらのタグは常に同じコンテンツを持ち、したがって、これらのタグから派生したソフトウェア識別子は、完全なタグのローカルコピーへのルックアップとして使用できます。ソースモデルとデータモデルの他の組み合わせの場合、サーバーは、完全なレコードの配信を要求しないと、識別子に関連付けられた特定のソフトウェア製品とバージョンを特定できない場合があります。ただし、そのような場合でも、受け取ったソフトウェア識別子を確実に追跡できる限り、この情報のダウンストリームコンシューマーが完全なレコードを必要とすることはありません。 SWIMA-PVはソフトウェア識別子を使用して、帯域幅効率の良い方法でエンドポイント上の特定のソフトウェア製品の存在を経時的に追跡できます。
There are two important limitations of Software Identifiers to keep in mind:
ソフトウェア識別子には、2つの重要な制限事項があります。
1. The identifiers do not necessarily change when the associated record changes. In some situations, a record in the endpoint's Software Inventory Evidence Collection will change due to new information becoming available or in order to correct prior errors in that information. Such changes might or might not result in changes to the Software Identifier, depending on the nature of the changes and the rules governing how Software Identifiers are derived from records of the appropriate data model.
1. 関連するレコードが変更されても、識別子は必ずしも変更されません。状況によっては、エンドポイントのソフトウェアインベントリエビデンスコレクションのレコードは、新しい情報が利用可能になるか、その情報の以前のエラーを修正するために変更されます。変更の性質および適切なデータモデルのレコードからソフトウェアIDがどのように導出されるかを管理するルールに応じて、このような変更はソフトウェアIDに変更をもたらす場合とそうでない場合があります。
2. It is possible that a single software product is installed on a single endpoint multiple times. If these multiple installation instances are reported by the same source using the same data format, then this can result in identical Software Identifiers for both installation instances. In other words, Software Identifiers might not uniquely identify installation instances; they are just intended to uniquely identify software products (which might have more than one installation instance). Instead, to reliably distinguish between multiple instances of a single software product, one needs to make use of Record Identifiers as described in Section 3.4.3.
2. 単一のソフトウェア製品が単一のエンドポイントに複数回インストールされる可能性があります。これらの複数のインストールインスタンスが同じデータ形式を使用して同じソースから報告された場合、両方のインストールインスタンスで同じソフトウェア識別子が生成される可能性があります。つまり、ソフトウェア識別子はインストールインスタンスを一意に識別しない場合があります。これらは、ソフトウェア製品（複数のインストールインスタンスがある場合があります）を一意に識別することを目的としています。代わりに、単一のソフトウェア製品の複数のインスタンスを確実に区別するには、セクション3.4.3で説明されているように、レコード識別子を使用する必要があります。
The Data Model Type consists of two fields: Data Model Type PEN and Data Model Type. ("PEN" stands for "Private Enterprise Number".) The combination of these fields is used to identify the type of data model of the associated software inventory record. The data model is significant not only because it informs the recipient of the data model of the associated record but also because the process for generating the Software Identifier for the record depends on the record's data model. Clearly identifying the type of data model from which the Software Identifier was derived thus provides useful context for that value.
データモデルタイプは、データモデルタイプPENとデータモデルタイプの2つのフィールドで構成されます。 （「PEN」は「プライベートエンタープライズ番号」を表します。）これらのフィールドの組み合わせは、関連するソフトウェアインベントリレコードのデータモデルのタイプを識別するために使用されます。データモデルは、関連するレコードのデータモデルを受信者に通知するだけでなく、レコードのソフトウェア識別子を生成するプロセスがレコードのデータモデルに依存するため、重要です。したがって、ソフトウェア識別子の派生元であるデータモデルのタイプを明確に特定すると、その値に役立つコンテキストが提供されます。
The PEN identifies the organization that assigns meaning to the Data Model Type field value. PENs are managed by IANA in the "Private Enterprise Numbers" registry. PENs allow vendors to designate their own set of data models for software inventory description. IANA reserves the PEN of 0x000000. Data Model Types associated with this PEN are defined in the "Software Data Model Types" registry; see Section 10.5 of this specification. Note that this IANA table reserves all values greater than or equal to 0xC0 (192) for local enterprise use. This means that local enterprises can use custom data formats and indicate them with the IANA PEN and a Data Model Type value between 0xC0 and 0xFF, inclusive. Those enterprises are responsible for configuring their SWIMA-PCs to correctly report those custom data models.
PENは、データモデルタイプフィールド値に意味を割り当てる組織を識別します。 PENは、IANAによって「Private Enterprise Numbers」レジストリで管理されています。 PENを使用すると、ベンダーはソフトウェアインベントリの説明用に独自のデータモデルセットを指定できます。 IANAは0x000000のPENを予約します。このPENに関連付けられているデータモデルタイプは、「ソフトウェアデータモデルタイプ」レジストリで定義されています。この仕様のセクション10.5を参照してください。このIANAテーブルは、ローカル企業で使用するために0xC0（192）以上のすべての値を予約していることに注意してください。これは、ローカル企業がカスタムデータ形式を使用し、IANA PENと0xC0から0xFFまでのデータモデルタイプ値でそれらを示すことができることを意味します。これらの企業は、それらのカスタムデータモデルを正しく報告するようにSWIMA-PCを構成する責任があります。
A Record Identifier is a 4-byte unsigned integer that is generated by the SWIMA-PC and is uniquely associated with a specific record within the endpoint's Software Inventory Evidence Collection. The SWIMA-PC MUST assign a unique identifier to each record when it is added to the endpoint's Software Inventory Evidence Collection. The Record Identifier SHOULD remain unchanged if that record is modified. However, it is recognized that, in some circumstances, record modification might be hard to distinguish from record deletion followed by creation of a new record. For this reason, retaining a constant Record Identifier across a record modification is recommended but not required. Similarly, in the case that the software product associated with a record is moved, ideally the Record Identifier for the record of the moved software will remain unchanged, reflecting that it represents the same software product instance, albeit in a new location. However, this level of tracking could prove difficult to achieve and is not required. The SWIMA-PC might wish to assign Record Identifiers sequentially, but any scheme is acceptable, provided that no two records receive the same identifier.
レコード識別子は、SWIMA-PCによって生成される4バイトの符号なし整数であり、エンドポイントのソフトウェアインベントリエビデンスコレクション内の特定のレコードに一意に関連付けられています。 SWIMA-PCは、エンドポイントのソフトウェアインベントリエビデンスコレクションに追加されるときに、各レコードに一意の識別子を割り当てる必要があります。そのレコードが変更された場合、レコード識別子は変更されないままである必要があります。ただし、状況によっては、レコードの変更は、レコードの削除とそれに続く新しいレコードの作成から区別するのが難しい場合があることが認識されています。このため、レコードの変更全体で一定のレコード識別子を保持することをお勧めしますが、必須ではありません。同様に、レコードに関連付けられたソフトウェア製品が移動された場合、理想的には、移動されたソフトウェアのレコードのレコード識別子は変更されないままで、新しい場所ではあるが同じソフトウェア製品インスタンスを表すことを反映します。ただし、このレベルの追跡は達成が困難であることが判明する可能性があるため、必須ではありません。 SWIMA-PCはレコードIDを順番に割り当てたいと思うかもしれませんが、2つのレコードが同じIDを受信しない限り、どのようなスキームも受け入れられます。
Servers can use Record Identifiers to distinguish between multiple instances of a single software product installed on an endpoint. Since each installation instance of a software product is associated with a separate record, servers can use the Record Identifier to distinguish between instances. For example, if an event is reported (as described in Section 3.7), the Record Identifier will allow the server to discern which instance of a software product is involved.
サーバーはレコード識別子を使用して、エンドポイントにインストールされている単一のソフトウェア製品の複数のインスタンスを区別できます。ソフトウェア製品の各インストールインスタンスは個別のレコードに関連付けられているため、サーバーはレコード識別子を使用してインスタンスを区別できます。たとえば、イベントが報告された場合（セクション3.7で説明）、レコード識別子により、サーバーはソフトウェア製品のどのインスタンスが関係しているかを識別できます。
In addition to the need to identify what software products are on an endpoint, some processes that use inventory information also need to know where software is located on the endpoint. This information might be needed to direct remediation actions or similar processes. For this reason, every reported software product also includes a Software Locator to identify where the software is installed on the endpoint.
エンドポイント上にあるソフトウェア製品を特定する必要性に加えて、インベントリ情報を使用する一部のプロセスは、ソフトウェアがエンドポイント上のどこにあるかを知る必要もあります。この情報は、修復アクションまたは同様のプロセスを指示するために必要になる場合があります。このため、報告されたすべてのソフトウェア製品には、ソフトウェアがエンドポイントのどこにインストールされているかを識別するためのソフトウェアロケーターも含まれています。
If the location is not provided directly by the data source, the SWIMA-PC is responsible for attempting to determine the location of the software product. The "location" of a product SHOULD be the directory in which the software product's executables are kept. The SWIMA-PC MUST be consistent in reporting the location of a software product. In other words, assuming that a software product has not moved, the SWIMA-PC cannot use one location in one report and a different location for the same software product in another. (If a software product has moved, the Software Locator needs to reflect the new location.)
場所がデータソースから直接提供されない場合、SWIMA-PCはソフトウェア製品の場所を特定しようとします。製品の「場所」は、ソフトウェア製品の実行可能ファイルが保持されるディレクトリにする必要があります（SHOULD）。 SWIMA-PCは、ソフトウェア製品の場所を報告する際に一貫している必要があります。つまり、ソフトウェア製品が移動していないと仮定すると、SWIMA-PCは、1つのレポートで1つの場所を使用し、別の場所で同じソフトウェア製品の別の場所を使用することはできません。 （ソフトウェア製品が移動した場合、Software Locatorは新しい場所を反映する必要があります。）
The location is expressed as a URI string. The string MUST conform to URI syntax requirements [RFC3986]. The URI scheme describes the context of the described location. For example, in most cases the location of the installed software product will be expressed in terms of its path in the filesystem. For such locations, the location URI scheme MUST be "file", and the URI MUST conform to the "file" URI scheme standard [RFC8089], including the percent-encoding of whitespace and other special characters. It is possible that other schemes could be used to represent other location contexts. Apart from specifying the use of the "file" scheme, this specification does not identify other schemes or define their use. When representing software products in other location contexts, tools MUST be consistent in their use of schemes, but the exact schemes are not normatively defined here. SWIMA implementations are not limited to the IANA list of URI schemes <https://www.iana.org/assignments/ uri-schemes/> and can define new schemes to support other types of application locations.
場所はURI文字列として表現されます。文字列はURI構文要件[RFC3986]に準拠する必要があります。 URIスキームは、記述された場所のコンテキストを記述します。たとえば、ほとんどの場合、インストールされたソフトウェア製品の場所は、ファイルシステム内のパスで表されます。このような場所の場合、場所URIスキームは「ファイル」である必要があり、URIは空白やその他の特殊文字のパーセントエンコーディングを含む「ファイル」URIスキーム標準[RFC8089]に準拠する必要があります。他のスキームを使用して、他の場所のコンテキストを表すことができる可能性があります。 「ファイル」スキームの使用を指定する以外に、この仕様は他のスキームを識別したり、それらの使用を定義したりしていません。他の場所のコンテキストでソフトウェア製品を表す場合、ツールはスキームの使用において一貫している必要がありますが、正確なスキームはここでは規範的に定義されていません。 SWIMA実装は、URIスキームのIANAリスト<https://www.iana.org/assignments/ uri-schemes />に限定されず、他のタイプのアプリケーションの場所をサポートする新しいスキームを定義できます。
It is possible that a SWIMA-PC is unable to determine the location of a reported software product. In this case, the SWIMA-PC MUST provide a zero-length Software Locator.
SWIMA-PCが報告されたソフトウェア製品の場所を判別できない可能性があります。この場合、SWIMA-PCは長さがゼロのソフトウェアロケータを提供する必要があります。
All SWIMA-PCs MUST track the source of each piece of software information they report. Each time a SWIMA-PC gets information to send to a given SWIMA-PV from a new source (from the perspective of that SWIMA-PV), the SWIMA-PC MUST assign that source a Source Identifier, which is an 8-bit unsigned integer. Each item reported includes the number of the Source Identifier for the source that provided that information. All information that is provided by that source MUST be delivered with this same Source Identifier. This MUST be done for each source used. If the SWIMA-PC is ever unclear as to whether a given source is new or not, it MUST assume that this is a new source and assign it a new Source Identifier. Source Identifier numbers do not need to be assigned sequentially. SWIMA does not support the presence of more than 256 sources, as the chance that a single endpoint will have more than 256 methods of collecting inventory information is vanishingly small. All possible values between 0 and 255 are valid; there are no reserved Source Identifier numbers.
すべてのSWIMA-PCは、報告する各ソフトウェア情報のソースを追跡する必要があります。 SWIMA-PCが新しいソースから特定のSWIMA-PVに送信する情報を取得するたびに（SWIMA-PVの観点から）、SWIMA-PCはそのソースに8ビットの署名されていないソース識別子を割り当てなければなりません（MUST）。整数。報告される各項目には、その情報を提供したソースのソース識別子の番号が含まれています。そのソースによって提供されるすべての情報は、この同じソース識別子とともに配信されなければなりません。これは、使用するソースごとに実行する必要があります。特定のソースが新しいかどうかについてSWIMA-PCが不明な場合は、これが新しいソースであると想定し、新しいソース識別子を割り当てる必要があります。ソースID番号を順番に割り当てる必要はありません。 SWIMAは256を超えるソースの存在をサポートしていません。これは、単一のエンドポイントが256を超える方法でインベントリ情報を収集する可能性がほとんどないためです。 0〜255のすべての可能な値が有効です。予約されたソース識別子番号はありません。
Source Identifiers can help with (although will not completely eliminate) the challenges posed by multiple reporting of a single software instance. If multiple sources each report the same type of software product once, there is most likely a single instance of that product installed on the endpoint, which each source has detected independently. On the other hand, if multiple instances are reported by a single source, this almost certainly means that there are actually multiple instances that are being reported.
ソース識別子は、単一のソフトウェアインスタンスの複数のレポートによって引き起こされる課題を（完全に排除するわけではありませんが）助けることができます。複数のソースがそれぞれ同じタイプのソフトウェア製品を1回報告する場合、エンドポイントにインストールされているその製品の単一のインスタンスが存在する可能性が高く、各ソースが個別に検出します。一方、複数のインスタンスが単一のソースによって報告されている場合、これはほぼ確実に、報告されている複数のインスタンスがあることを意味します。
The SWIMA-PC is responsible for tracking associations between Source Identifiers and the given data source. This association MUST remain consistent with regard to a given SWIMA-PV while there is an active PB-TNC session with that SWIMA-PV. The SWIMA-PC MAY have a different Source Identifier association for different SWIMA-PVs. Likewise, the SWIMA-PC MAY change the Source Identifier association for a given SWIMA-PV if the PB-TNC session terminates. However, implementers of SWIMA-PCs will probably find it easier to manage associations by maintaining the same association for all SWIMA-PVs and across multiple sessions.
SWIMA-PCは、ソース識別子と指定されたデータソース間の関連付けの追跡を担当します。この関連付けは、そのSWIMA-PVとのアクティブなPB-TNCセッションがある間、特定のSWIMA-PVに関して一貫性を保つ必要があります。 SWIMA-PCは、異なるSWIMA-PVに対して異なるソース識別子の関連付けを持つ場合があります。同様に、PB-TNCセッションが終了した場合、SWIMA-PCは特定のSWIMA-PVの送信元識別子の関連付けを変更する場合があります。ただし、SWIMA-PCの実装者は、すべてのSWIMA-PVに対して同じ関連付けを維持し、複数のセッションにわたって関連付けることで、関連付けの管理がより簡単になるでしょう。
Of special note, event records reported from the SWIMA-PC's event log (discussed in Section 3.7) also need to be sent with their associated data source. The Source Identifier reported with events MUST be the current (i.e., at the time the event is sent) Source Identifier associated with the data source that produced the event, regardless of how long ago that event occurred. Event logs are likely to persist far longer than a single PB-TNC session. SWIMA-PCs MUST ensure that each event can be linked to the appropriate data source, even if the Source Identifiers used when the event was created have since been reassigned. In other words, when sending an event, it needs to be sent with the Source Identifier currently linked to the data source that produced it, regardless of whether a different Source Identifier would have been associated with the event when the event was first created.
特に、SWIMA-PCのイベントログ（セクション3.7で説明）から報告されたイベントレコードも、関連するデータソースとともに送信する必要があります。イベントと共に報告されるソース識別子は、そのイベントが発生した時間に関係なく、イベントを生成したデータソースに関連付けられた現在の（つまり、イベントが送信された時点の）ソース識別子である必要があります。イベントログは、単一のPB-TNCセッションよりもはるかに長く持続する可能性があります。 SWIMA-PCは、イベントの作成時に使用されたソース識別子が割り当て直された後でも、各イベントを適切なデータソースにリンクできることを確認する必要があります。つまり、イベントを送信するときは、イベントが最初に作成されたときに別のソース識別子がイベントに関連付けられていたかどうかに関係なく、イベントを生成したデータソースに現在リンクされているソース識別子で送信する必要があります。
Note that the Source Identifier is primarily used to support recognition, rather than identification, of sources. That is to say, a Source Identifier can tell a recipient that two events were reported by the same source, but the number will not necessarily help that recipient determine which source was used. Moreover, different SWIMA-PCs will not necessarily use the same Source Identifiers for the same sources. SWIMA-PCs MUST track the assignment of Source Identifiers to ensure consistent application thereof. SWIMA-PCs MUST also track which Source Identifiers have been used with each SWIMA-PV with which they communicate.
ソース識別子は、ソースの識別ではなく、主に認識をサポートするために使用されることに注意してください。つまり、ソース識別子は、2つのイベントが同じソースによって報告されたことを受信者に伝えることができますが、その数は必ずしもその受信者がどのソースが使用されたかを判断するのに役立つとは限りません。さらに、異なるSWIMA-PCは、必ずしも同じソースに対して同じソース識別子を使用するわけではありません。 SWIMA-PCは、ソースIDの割り当てを追跡して、その一貫した適用を保証する必要があります。 SWIMA-PCは、通信する各SWIMA-PVで使用されたソース識別子も追跡する必要があります。
A SWIMA attribute reporting an endpoint's Software Inventory Evidence Collection always contains the Software Identifiers associated with the identified software products. A SWIMA attribute might or might not also contain copies of Software Inventory Evidence Records. The attribute exchange is identical to the diagram shown in Figure 2, regardless of whether Software Inventory Evidence Records are included. The SWIMA Request attribute indicates whether the response is required to include Software Inventory Evidence Records. Excluding Software Inventory Evidence Records can reduce the attribute size of the response by multiple orders of magnitude when compared to sending the same inventory with full records.
エンドポイントのソフトウェアインベントリエビデンスコレクションを報告するSWIMA属性には、識別されたソフトウェア製品に関連付けられたソフトウェア識別子が常に含まれています。 SWIMA属性には、ソフトウェアインベントリエビデンスレコードのコピーが含まれる場合と含まれない場合があります。属性の交換は、ソフトウェアインベントリエビデンスレコードが含まれているかどうかに関係なく、図2に示す図と同じです。 SWIMA要求属性は、応答にソフトウェアインベントリエビデンスレコードを含める必要があるかどうかを示します。ソフトウェアインベントリエビデンスレコードを除外すると、完全なレコードで同じインベントリを送信する場合と比較して、応答の属性サイズを数桁減らすことができます。
Sometimes a SWIMA-PV does not require information about every piece of software on an endpoint but only needs to receive updates about certain software instances. For example, enterprise endpoints might be required to have certain software products installed and to keep these updated. Instead of requesting a complete inventory just to see if these products are present, the SWIMA-PV can make a "targeted request" for the software in question.
SWIMA-PVは、エンドポイント上のすべてのソフトウェアに関する情報を必要とせず、特定のソフトウェアインスタンスに関する更新のみを受信する必要がある場合があります。たとえば、エンタープライズエンドポイントには、特定のソフトウェア製品をインストールし、これらを最新の状態に保つ必要がある場合があります。これらの製品が存在するかどうかを確認するためだけに完全なインベントリを要求する代わりに、SWIMA-PVは問題のソフトウェアに対して「ターゲットを絞った要求」を行うことができます。
Targeted requests follow the same attribute exchange as the exchange described in Figure 2. The SWIMA-PV targets its request by providing one or more Software Identifiers in its SWIMA Request attribute. The SWIMA-PC MUST then limit its response to contain only records that match the indicated Software Identifier(s). This allows the network exchange to exclude information that is not relevant to a given policy question, thus reducing unnecessary bandwidth consumption. The SWIMA-PC's response might or might not include Software Inventory Evidence Records, depending on the parameters of the SWIMA Request.
ターゲット要求は、図2で説明されている交換と同じ属性交換に従います。SWIMA-PVは、SWIMA要求属性に1つ以上のソフトウェア識別子を提供することにより、その要求をターゲットにします。次に、SWIMA-PCは、指定されたソフトウェア識別子と一致するレコードのみを含むように応答を制限する必要があります。これにより、ネットワーク交換で特定のポリシーの質問に関係のない情報を除外できるため、不要な帯域幅の消費を削減できます。 SWIMA-PCの応答には、SWIMAリクエストのパラメーターに応じて、ソフトウェアインベントリエビデンスレコードが含まれる場合と含まれない場合があります。
Note that targeted requests identify the software relevant to the request only through Software Identifiers. This specification does not support arbitrary, parameterized querying of records. For example, one cannot request all records from a certain software publisher or all records created by a particular data source. Targeted requests only allow a requester to request specific software (as identified by their Software Identifiers) and receive a response that is limited to the named software.
ターゲットを絞ったリクエストは、ソフトウェア識別子を通じてのみリクエストに関連するソフトウェアを識別することに注意してください。この仕様は、レコードの任意のパラメーター化されたクエリをサポートしていません。たとえば、特定のソフトウェア発行元にすべてのレコードを要求したり、特定のデータソースによって作成されたすべてのレコードを要求したりすることはできません。ターゲットを絞ったリクエストでは、リクエスターは特定のソフトウェア（ソフトウェアIDで識別される）をリクエストし、指定されたソフトウェアに限定された応答を受け取ることができます。
There is no assumption that a SWIMA-PC will recognize "synonymous records" -- that is, records from different sources for the same software. Recall that different sources and data models may use different Software Identifier strings for the same software product. The SWIMA-PC returns only records that match the Software Identifiers in the SWIMA Request, even if there might be other records in the endpoint's Software Inventory Evidence Collection for the same software product. This is necessary because SWIMA-PCs might not have the ability to determine that two Software Identifiers refer to the same product.
SWIMA-PCが「同義のレコード」、つまり同じソフトウェアの異なるソースからのレコードを認識するという仮定はありません。異なるソースとデータモデルでは、同じソフトウェア製品に対して異なるソフトウェア識別子文字列を使用する場合があることを思い出してください。同じソフトウェア製品のエンドポイントのソフトウェアインベントリエビデンスコレクションに他のレコードが存在する場合でも、SWIMA-PCはSWIMAリクエストのソフトウェア識別子と一致するレコードのみを返します。 SWIMA-PCは2つのソフトウェア識別子が同じ製品を参照していると判断できない場合があるため、これが必要です。
A targeted SWIMA Request attribute does not specify Record Identifiers or Software Locators. The response to a targeted request MUST include all records associated with the named Software Identifiers, including the case where there are multiple records associated with a single Software Identifier.
ターゲットのSWIMA要求属性は、レコード識別子またはソフトウェアロケーターを指定しません。対象となるリクエストへの応答には、単一のソフトウェア識別子に関連付けられた複数のレコードがある場合を含め、指定されたソフトウェア識別子に関連付けられたすべてのレコードを含める必要があります。
SWIMA-PCs MUST accept targeted requests and process them correctly as described above. SWIMA-PVs MUST be capable of making targeted requests and processing the responses thereto.
SWIMA-PCは、ターゲットのリクエストを受け入れ、上記のように正しく処理する必要があります。 SWIMA-PVは、ターゲットを絞った要求を作成し、その応答を処理できる必要があります。
3.6. Monitoring Changes in an Endpoint's Software Inventory Evidence Collection
3.6. エンドポイントのソフトウェアインベントリエビデンスコレクションの変更の監視
The software collection on an endpoint is not static. As software is installed, uninstalled, patched, or updated, the Software Inventory Evidence Collection is expected to change to reflect the new software state on the endpoint. Different data sources might update the evidence collection at different rates. For example, a package manager might update its records in the Software Inventory Evidence Collection immediately whenever it is used to add or remove a software product. By contrast, sources that perform periodic examination of the endpoint would likely only update their records in the Software Inventory Evidence Collection after each examination.
エンドポイントのソフトウェアコレクションは静的ではありません。ソフトウェアがインストール、アンインストール、パッチ適用、または更新されると、ソフトウェアインベントリエビデンスコレクションは、エンドポイントの新しいソフトウェアの状態を反映するように変更されることが予想されます。データソースが異なると、証拠収集が異なる速度で更新される場合があります。たとえば、パッケージマネージャーは、ソフトウェア製品の追加または削除に使用されるたびに、ソフトウェアインベントリエビデンスコレクションのレコードをすぐに更新する場合があります。対照的に、エンドポイントの定期的な検査を実行するソースは、各検査後にソフトウェアインベントリエビデンスコレクションのレコードのみを更新する可能性があります。
All SWIMA-PCs MUST be able to detect changes to the Software Inventory Evidence Collection. Specifically, SWIMA-PCs MUST be able to detect:
すべてのSWIMA-PCは、ソフトウェアインベントリエビデンスコレクションへの変更を検出できる必要があります。具体的には、SWIMA-PCは以下を検出できる必要があります。
o The creation of records
o レコードの作成
o The deletion of records
o レコードの削除
o The alteration of records
o 記録の改ざん
An "alteration" is anything that modifies the contents of a record (or would modify it, if the record is dynamically generated on demand) in any way, regardless of whether the change is functionally meaningful.
「変更」とは、変更が機能的に意味があるかどうかに関係なく、レコードの内容を変更する（または、レコードがオンデマンドで動的に生成される場合は変更する）方法です。
SWIMA-PCs MUST detect such changes to the endpoint's Software Inventory Evidence Collection in close to real time (i.e., within seconds) when the SWIMA-PC is operating. In addition, in the case where there is a period during which the SWIMA-PC is not operating, the SWIMA-PC MUST be able to determine the net change to the endpoint's Software Inventory Evidence Collection over the period it was not operational. Specifically, the "net change" represents the difference between (1) the state of the endpoint's Software Inventory Evidence Collection when the SWIMA-PC was last operational and monitoring its state and (2) the state of the endpoint's Software Inventory Evidence Collection when the SWIMA-PC resumed operation. Note that a net change might not reflect the total number of change events over this interval. For example, if a record was altered three times during a period when the SWIMA-PC was unable to monitor for changes, the net change of this interval might only note that there was an alteration to the record, but not how many individual alteration events occurred. It is sufficient for a SWIMA-PC's determination of a net change to note that there was a difference between the earlier and current state, rather than to enumerate all the individual events that allowed the current state to be reached.
SWIMA-PCが動作しているとき、SWIMA-PCは、エンドポイントのソフトウェアインベントリエビデンスコレクションに対するこのような変更をリアルタイムに近い（つまり、数秒以内）で検出する必要があります。さらに、SWIMA-PCが動作していない期間がある場合、SWIMA-PCは、動作していない期間におけるエンドポイントのソフトウェアインベントリエビデンスコレクションへの正味の変更を判別できなければなりません（MUST）。具体的には、「正味の変化」は、（1）SWIMA-PCが最後に動作して状態を監視していたエンドポイントのソフトウェアインベントリエビデンスコレクションの状態と、（2）エンドポイントのソフトウェアインベントリエビデンスコレクションの状態がSWIMA-PCが操作を再開しました。正味の変更は、この間隔での変更イベントの総数を反映しない場合があることに注意してください。たとえば、SWIMA-PCが変更を監視できなかった期間にレコードが3回変更された場合、この間隔の正味の変更では、レコードに変更があったことだけが記録され、個々の変更イベントの数は記録されません。発生した。 SWIMA-PCが正味の変化を判断するためには、現在の状態に到達することを可能にする個々のイベントをすべて列挙するのではなく、以前の状態と現在の状態の間に違いがあったことを指摘するだけで十分です。
The SWIMA-PC MUST assign a time to each detected change in the endpoint's Software Inventory Evidence Collection. These timestamps correspond to the SWIMA-PC's best understanding as to when the detected change occurred. For changes to the endpoint's Software Inventory Evidence Collection that occur while the SWIMA-PC is operating, the SWIMA-PC ought to be able to assign a time to the event that is accurate to within a few seconds. For changes to the endpoint's Software Inventory Evidence Collection that occur while the SWIMA-PC is not operational, upon becoming operational the SWIMA-PC needs to make a best guess as to the time of the relevant events (possibly by looking at timestamps on files), but these values might be off. In the case of dynamically generated records, the time of change is the time at which the data from which the records are generated changes, not the time at which a changed record is generated. For example, if records are dynamically generated based on data in an RPM database (<http://rpm.org/>), the time of change would be when the RPM database changed.
SWIMA-PCは、エンドポイントのソフトウェアインベントリエビデンスコレクションで検出された各変更に時間を割り当てる必要があります。これらのタイムスタンプは、検出された変更がいつ発生したかに関するSWIMA-PCの最良の理解に対応しています。 SWIMA-PCの動作中に発生するエンドポイントのソフトウェアインベントリエビデンスコレクションへの変更の場合、SWIMA-PCは数秒以内の正確な時間をイベントに割り当てることができるはずです。 SWIMA-PCが動作していないときに発生するエンドポイントのソフトウェアインベントリエビデンスコレクションへの変更の場合、動作可能になると、SWIMA-PCは関連するイベントの時刻を推測する必要があります（ファイルのタイムスタンプを調べることにより）。 、ただしこれらの値はオフになっている可能性があります。動的に生成されたレコードの場合、変更の時刻は、レコードの生成元のデータが変更された時刻であり、変更されたレコードが生成された時刻ではありません。たとえば、RPMデータベース（<http://rpm.org/>）のデータに基づいてレコードが動的に生成される場合、変更のタイミングはRPMデータベースが変更されたときです。
With regard to deletions of records, the SWIMA-PC needs to detect the deletion of a given record and MUST retain a copy of the full deleted record along with the associated Record Identifier and Software Locator so that the record and associated information can be provided to the SWIMA-PV upon request. This copy of the record MUST be retained for a reasonable amount of time. Vendors and administrators determine what "reasonable" means, but a copy of the record SHOULD be retained for as long as the event recording the deletion of the record remains in the SWIMA-PC's event log (as described in Section 3.7). This is recommended, because as long as the event is in the SWIMA-PC's event log the SWIMA-PC might send a change event attribute (described in Section 3.7) that references this record, and a copy of the record is needed if the SWIMA-PV wants a full copy of the relevant record. In the case that a SWIMA-PC is called upon to report a deletion event that is still in the event log but where the record itself is no longer available, the SWIMA-PC will still return an entry corresponding to the deletion event, but the field of that entry that would normally contain the full copy of the record SHOULD be zero-length.
レコードの削除に関して、SWIMA-PCは指定されたレコードの削除を検出する必要があり、削除された完全なレコードのコピーを、関連付けられたレコード識別子とソフトウェアロケータとともに保持して、レコードと関連情報を提供できるようにする必要があります。ご要望に応じてSWIMA-PV。この記録のコピーは、妥当な期間保持されなければなりません。ベンダーと管理者は「合理的」な意味を決定しますが、レコードの削除を記録するイベントがSWIMA-PCのイベントログに残っている限り（セクション3.7で説明）、レコードのコピーを保持する必要があります（SHOULD）。イベントがSWIMA-PCのイベントログにある限り、SWIMA-PCはこのレコードを参照する変更イベント属性（3.7項で説明）を送信する可能性があるため、これが推奨されます。SWIMAの場合、レコードのコピーが必要です。 -PVは関連レコードの完全なコピーを必要としています。 SWIMA-PCがまだイベントログにある削除イベントを報告するように要求されたが、レコード自体が利用できなくなった場合、SWIMA-PCは削除イベントに対応するエントリを返しますが、通常、レコードの完全なコピーが含まれるそのエントリのフィールドは、長さがゼロである必要があります。
With regard to alterations to a record, SWIMA-PCs MUST detect any alterations to the contents of a record. Alterations need to be detected even if they have no functional impact on the record. A good guideline is that any alteration to a record that might change the value of a hash taken on the record's contents needs to be detected by the SWIMA-PC. A SWIMA-PC might be unable to distinguish modifications to the contents of a record from modifications to the metadata that the filesystem associates with the record. For example, a SWIMA-PC might use the "last modification" timestamp as an indication of alteration to a given record, but a record's last modification time can change for reasons other than modifications to the record's contents. A SWIMA-PC is still considered compliant with this specification if it also reports metadata change events that do not change the record itself as alterations to the record. In other words, while SWIMA-PC implementers are encouraged to exclude modifications that do not affect the bytes within the record, discriminating between modifications to file contents and changes to file metadata can be difficult and time consuming on some systems. As such, as long as the alterations detected by a SWIMA-PC always cover all modifications to the contents of a record, the SWIMA-PC is considered compliant even if it also registers alterations that do not modify the contents of a record as well. When recording an alteration to a record, the SWIMA-PC is only required to note that an alteration occurred. The SWIMA-PC is not required to note or record how the record was altered, nor is it possible to include such details in SWIMA attributes reporting the change to a SWIMA-PV. There is no need to retain a copy of the original record prior to the alteration.
レコードの変更に関して、SWIMA-PCはレコードの内容の変更を検出する必要があります。レコードに機能的な影響がない場合でも、変更を検出する必要があります。良いガイドラインは、レコードの内容で作成されたハッシュの値を変更する可能性があるレコードへの変更は、SWIMA-PCによって検出される必要があることです。 SWIMA-PCは、レコードの内容に対する変更を、ファイルシステムがレコードに関連付けるメタデータに対する変更と区別できない場合があります。たとえば、SWIMA-PCは「最終変更」タイムスタンプを特定のレコードへの変更の指標として使用しますが、レコードの最終変更時刻は、レコードの内容の変更以外の理由で変更される場合があります。 SWIMA-PCは、レコード自体を変更しないメタデータ変更イベントもレコードへの変更として報告する場合、この仕様に準拠していると見なされます。つまり、SWIMA-PCの実装者は、レコード内のバイトに影響を与えない変更を除外することをお勧めしますが、一部のシステムでは、ファイルコンテンツの変更とファイルメタデータの変更を区別することは困難で時間がかかる場合があります。したがって、SWIMA-PCによって検出された変更が常にレコードの内容に対するすべての変更をカバーしている限り、SWIMA-PCがレコードの内容を変更しない変更も登録している場合でも、SWIMA-PCは準拠していると見なされます。レコードに変更を記録する場合、SWIMA-PCは変更が発生したことを記録するだけで済みます。 SWIMA-PCは、レコードがどのように変更されたかを記録または記録する必要はありません。また、SWIMA-PVへの変更を報告するSWIMA属性にそのような詳細を含めることもできません。変更前の元のレコードのコピーを保持する必要はありません。
When a record changes, it SHOULD retain the same Record Identifier. The Software Locator might or might not change, depending on whether the software changed locations during the changes that led to the record change. A record change MUST retain the same Software Identifier. This means that any action that changes a software product (e.g., application of a patch that results in a change to the product's version) MUST NOT be reflected by a record change but instead MUST result in the deletion of the old record and the creation of a new record. This reflects the requirement that a record in the endpoint's Software Inventory Evidence Collection correspond directly with an instance of a specific software product.
レコードが変更されても、同じレコード識別子を保持する必要があります。 Software Locatorは、レコードの変更につながる変更中にソフトウェアが場所を変更したかどうかによって、変更される場合と変更されない場合があります。レコードの変更は、同じソフトウェア識別子を保持する必要があります。これは、ソフトウェア製品を変更するアクション（製品のバージョンの変更をもたらすパッチの適用など）は、レコードの変更によって反映されてはならず、代わりに古いレコードの削除および新しい記録。これは、エンドポイントのソフトウェアインベントリエビデンスコレクションのレコードが特定のソフトウェア製品のインスタンスに直接対応するという要件を反映しています。
As noted in Section 3.6, SWIMA-PCs are required to detect changes to the endpoint's Software Inventory Evidence Collection (creation, deletion, and alteration) in near real time while the SWIMA-PC is operational, and a given SWIMA-PC MUST be able to account for any net change to the endpoint's Software Inventory Evidence Collection that occurs when the SWIMA-PC is not operational. However, to be of use to the enterprise, the NEA Server needs to be able to receive these events and be able to understand how new changes relate to earlier changes. In SWIMA, this is facilitated by reporting change events. All SWIMA-PCs MUST be capable of receiving requests for change events and sending change event attributes. All SWIMA-PVs MUST be capable of requesting and receiving change event attributes.
セクション3.6で述べたように、SWIMA-PCは、SWIMA-PCが動作している間、エンドポイントのソフトウェアインベントリエビデンスコレクションへの変更（作成、削除、および変更）をほぼリアルタイムで検出する必要があり、特定のSWIMA-PCは、 SWIMA-PCが動作していないときに発生する、エンドポイントのソフトウェアインベントリエビデンスコレクションに対する正味の変更を説明します。ただし、企業で使用するには、NEAサーバーがこれらのイベントを受信し、新しい変更が以前の変更とどのように関連しているかを理解できる必要があります。 SWIMAでは、変更イベントを報告することでこれが容易になります。すべてのSWIMA-PCは、変更イベントの要求を受信し、変更イベント属性を送信できる必要があります。すべてのSWIMA-PVは、変更イベント属性を要求および受信できる必要があります。
To be useful, change events need to be correctly ordered. The ordering of events is facilitated by two pieces of information: an Event Identifier (EID) value and an EID Epoch value.
役立つためには、変更イベントを正しく順序付ける必要があります。イベントの順序付けは、イベントID（EID）値とEIDエポック値という2つの情報によって容易になります。
An EID is a 4-byte unsigned integer that the SWIMA-PC assigns sequentially to each observed event (whether detected in real time or deduced by looking for net changes over a period of SWIMA-PC inactivity). All EIDs exist within the context of some "EID Epoch", which is also represented as a 4-byte unsigned integer. EID Epochs are used to ensure synchronization between the SWIMA-PC and any SWIMA-PVs with which it communicates. EID Epoch values MUST be generated in such a way as to minimize the chance that an EID Epoch will be reused, even in the case where the SWIMA-PC reverts to an earlier state. For this reason, sequential EID Epochs are discouraged, since loss of state could result in value reuse. There are multiple reasons that a SWIMA-PC might need to deliberately reset its EID counter, including exhaustion of available EID values, the need to purge entries from the event log to recover memory, or corruption of the event log. In all cases where a SWIMA-PC needs to reset its EID counter, a new EID Epoch MUST be selected.
EIDは、4バイトの符号なし整数であり、SWIMA-PCが観測された各イベントに順次割り当てます（リアルタイムで検出されるか、SWIMA-PCの非アクティブ期間中の正味の変化を探すことによって推定されるか）。すべてのEIDは、一部の「EIDエポック」のコンテキスト内に存在します。これは、4バイトの符号なし整数としても表されます。 EIDエポックは、SWIMA-PCと通信するSWIMA-PV間の同期を確実にするために使用されます。 EIDエポック値は、SWIMA-PCが以前の状態に戻った場合でも、EIDエポックが再利用される可能性を最小限に抑えるような方法で生成する必要があります。このため、状態が失われると値が再利用される可能性があるため、連続するEIDエポックは推奨されません。利用可能なEID値の枯渇、メモリを回復するためにイベントログからエントリを削除する必要、イベントログの破損など、SWIMA-PCが意図的にEIDカウンタをリセットする必要がある理由はいくつかあります。 SWIMA-PCがEIDカウンターをリセットする必要があるすべてのケースで、新しいEIDエポックを選択する必要があります。
Within an Epoch, EIDs MUST be assigned sequentially, so that if a particular event is assigned an EID of N, the next observed event is given an EID of N+1. In some cases, events might occur simultaneously, or the SWIMA-PC might not otherwise be able to determine an ordering for events. In these cases, the SWIMA-PC creates an arbitrary ordering of the events and assigns EIDs according to this ordering. Two change events MUST NOT ever be assigned the same EID within the same EID Epoch. No meaningful comparison can be made between EID values of different Epochs.
エポック内では、EIDを順番に割り当てる必要があるため、特定のイベントにNのEIDが割り当てられている場合、次の観測イベントにはN + 1のEIDが与えられます。イベントが同時に発生する場合や、SWIMA-PCがイベントの順序を決定できない場合があります。これらの場合、SWIMA-PCはイベントの任意の順序を作成し、この順序に従ってEIDを割り当てます。同じEIDエポック内で2つの変更イベントに同じEIDを割り当ててはなりません。異なるエポックのEID値の間で意味のある比較を行うことはできません。
The EID value of 0 is reserved and MUST NOT be associated with any event. Specifically, an EID of 0 in a SWIMA Request attribute indicates that a SWIMA-PV wants an inventory response rather than an event response, while an EID of 0 in a SWIMA Response is used to indicate the initial state of the endpoint's Software Inventory Evidence Collection prior to the observation of any events. Thus, the very first recorded event in a SWIMA-PC's records within an EID Epoch MUST be assigned a value of 1. Note that EID and EID Epoch values are assigned by the SWIMA-PC without regard to whether events are being reported to one or more SWIMA-PVs. The SWIMA-PC records events and assigns EIDs during its operation. All SWIMA-PVs that request event information from the SWIMA-PC will have those requests served from the same event records and thus will see the same EIDs and EID Epochs for the same events.
EID値0は予約されており、イベントに関連付けることはできません。具体的には、SWIMA要求属性のEIDが0の場合、SWIMA-PVがイベント応答ではなくインベントリ応答を要求していることを示し、SWIMA応答のEIDが0の場合は、エンドポイントのソフトウェアインベントリエビデンスコレクションの初期状態を示します。イベントを観察する前。したがって、EIDエポック内のSWIMA-PCのレコードで最初に記録されたイベントには、値1を割り当てる必要があります。EIDおよびEIDエポックの値は、イベントが1つに報告されているかどうかに関係なく、SWIMA-PCによって割り当てられることに注意してください。より多くのSWIMA-PV。 SWIMA-PCは、その動作中にイベントを記録し、EIDを割り当てます。 SWIMA-PCからイベント情報を要求するすべてのSWIMA-PVは、同じイベントレコードからそれらの要求を処理するため、同じイベントの同じEIDとEIDエポックが表示されます。
If a SWIMA-PC uses multiple sources, a SWIMA-PC's assignment of EIDs MUST reflect the presence and order of all events on the endpoint (at least for supported sources), regardless of the source. This means that if source A experiences an event and then source B experiences two events, and then source A experiences another two events, the SWIMA-PC is required to capture five events with consecutive EID values reflecting the order in which the events occurred.
SWIMA-PCが複数のソースを使用する場合、EIDのSWIMA-PCの割り当ては、ソースに関係なく、エンドポイント上のすべてのイベントの存在と順序を反映する必要があります（少なくともサポートされているソースの場合）。つまり、ソースAでイベントが発生し、次にソースBで2つのイベントが発生し、次にソースAで別の2つのイベントが発生した場合、SWIMA-PCは、イベントが発生した順序を反映するEID値が連続する5つのイベントをキャプチャする必要があります。
The SWIMA-PC MUST ensure that there is no coverage gap (i.e., change events that are not recorded in the SWIMA-PC's records) in its change event records. This is necessary because a coverage gap might give a SWIMA-PV a false impression of the endpoint's state. For example, if a SWIMA-PV saw an event indicating that a particular record had been added to the endpoint's Software Inventory Evidence Collection but did not see any subsequent events indicating that the record in question had been deleted, it might reasonably assume that this record was still present and thus that the indicated software was still installed (assuming that the Epoch has not changed). If there is a coverage gap in the SWIMA-PC's event records, however, this assumption could be false. For this reason, the SWIMA-PC's event records MUST NOT contain gaps. In the case where there are periods where it is possible that changes occurred without the SWIMA-PC detecting or recording them, the SWIMA-PC MUST either (1) compute a net change and update its event records appropriately or (2) pick a new EID Epoch to indicate a discontinuity with previous event records.
SWIMA-PCは、変更イベントレコードにカバレッジギャップがないことを確認する必要があります（つまり、SWIMA-PCのレコードに記録されていない変更イベント）。これは、カバレッジギャップがSWIMA-PVにエンドポイントの状態の誤った印象を与える可能性があるために必要です。たとえば、SWIMA-PVが、特定のレコードがエンドポイントのソフトウェアインベントリエビデンスコレクションに追加されたことを示すイベントを確認したが、問題のレコードが削除されたことを示す後続のイベントを確認しなかった場合、このレコードはがまだ存在していたため、示されたソフトウェアがまだインストールされていた（エポックが変更されていないと想定）。ただし、SWIMA-PCのイベントレコードにカバレッジギャップがある場合、この仮定は誤っている可能性があります。このため、SWIMA-PCのイベントレコードにギャップがあってはなりません。 SWIMA-PCが変更を検出または記録せずに変更が発生した可能性がある期間がある場合、SWIMA-PCは、（1）正味の変更を計算してそのイベントレコードを適切に更新するか、または（2）新しいものを選択する必要があります。 EIDエポックは、以前のイベントレコードとの不連続を示します。
Within a given Epoch, once a particular event has been assigned an EID, this association MUST NOT be changed. That is, within an Epoch, once an EID is assigned to an event, that EID cannot be reassigned to a different event, and the event cannot be assigned a different EID. When the SWIMA-PC's Epoch changes, all of these associations between EIDs and events are cancelled, and EID values once again become free for assignment.
特定のエポック内で、特定のイベントにEIDが割り当てられると、この関連付けは変更してはなりません（MUST NOT）。つまり、エポック内では、EIDがイベントに割り当てられると、そのEIDを別のイベントに再割り当てしたり、イベントに別のEIDを割り当てたりすることはできません。 SWIMA-PCのエポックが変更されると、EIDとイベントの間のこれらの関連付けはすべて取り消され、EID値は再び割り当て用に解放されます。
Whether reporting events or full inventories, it is important to know how the reported information fits into the overall timeline of change events. This is why all SWIMA Response attributes include fields to place that response within the sequence of detected events. Specifically, all SWIMA Responses include a Last EID field and an EID Epoch field. The EID Epoch field identifies the EID Epoch in which the SWIMA Response was sent. If the SWIMA Response is reporting events, all reported events occurred within the named EID Epoch. The Last EID (which is also always from the named EID Epoch) indicates the EID of the last recorded change event at the time that the SWIMA Response was sent. These two fields allow any response to be placed in the context of the complete set of detected change events within a given EID Epoch.
イベントを報告する場合でも、完全なインベントリを作成する場合でも、報告される情報が変更イベントの全体的なタイムラインにどのように適合するかを知ることが重要です。これが、すべてのSWIMA応答属性に、検出されたイベントのシーケンス内にその応答を配置するフィールドが含まれている理由です。特に、すべてのSWIMA応答には、Last EIDフィールドとEIDエポックフィールドが含まれています。 EIDエポックフィールドは、SWIMA応答が送信されたEIDエポックを識別します。 SWIMA応答がイベントを報告している場合、報告されたすべてのイベントは、指定されたEIDエポック内で発生しました。最後のEID（これも常に名前付きEIDエポックからのもの）は、SWIMA応答が送信されたときに最後に記録された変更イベントのEIDを示します。これらの2つのフィールドを使用すると、特定のEIDエポック内で検出された変更イベントの完全なセットのコンテキストに応答を配置できます。
Modern endpoints can have hundreds of software products installed, most of which are unlikely to change from one day to the next. As such, instead of exchanging a complete list of an endpoint's inventory on a regular basis, one might wish to only identify changes since some earlier known state of this inventory. This is readily facilitated by the use of EIDs to place change events in a context relative to the earlier state.
最新のエンドポイントには数百のソフトウェア製品がインストールされている可能性があり、そのほとんどが日によって変わる可能性はほとんどありません。そのため、エンドポイントのインベントリの完全なリストを定期的に交換する代わりに、このインベントリの以前の既知の状態以降の変更のみを識別したい場合があります。これは、EIDを使用して変更イベントを以前の状態に関連するコンテキストに配置することで簡単に促進されます。
As noted above, every SWIMA Response sent by a SWIMA-PC to a SWIMA-PV (as described in Sections 3.3 through 3.5) includes the EID Epoch and EID of the last event recorded prior to that response being compiled. This allows the SWIMA-PV to place all subsequently received event records in context relative to this SWIMA Response attribute (since the EIDs represent a total ordering of all changes to the endpoint's Software Inventory Evidence Collection). Specifically, a SWIMA-PV (or, more likely, a database that collects and records its findings) can record an endpoint's full inventory and also the EID and Epoch of the most recent event reflected at the time of that inventory. From that point on, if change events are observed, the attribute describing these events indicates the nature of the change, the affected records, and the order in which these events occurred (as indicated by the sequential EIDs). Using this information, any remote record of the endpoint's Software Inventory Evidence Collection can be updated appropriately.
上記のように、SWIMA-PCからSWIMA-PVに送信されるすべてのSWIMA応答（セクション3.3〜3.5で説明）には、その応答がコンパイルされる前に記録された最後のイベントのEIDエポックとEIDが含まれます。これにより、SWIMA-PVは、その後受信したすべてのイベントレコードを、このSWIMA応答属性に関連するコンテキストに配置できます（EIDは、エンドポイントのソフトウェアインベントリエビデンスコレクションに対するすべての変更の合計順序を表すため）。具体的には、SWIMA-PV（または、より可能性としては、その結果を収集して記録するデータベース）は、エンドポイントの完全なインベントリと、そのインベントリの時点で反映された最新のイベントのEIDとエポックも記録できます。その時点以降、変更イベントが観察された場合、これらのイベントを説明する属性は、変更の性質、影響を受けるレコード、およびこれらのイベントが発生した順序（順次EIDで示される）を示します。この情報を使用して、エンドポイントのソフトウェアインベントリエビデンスコレクションのリモートレコードを適切に更新できます。
A SWIMA-PV MUST be able to request a list of event records instead of an inventory. The attribute flow in such an exchange looks the same as the basic flow shown in Figure 2. The only difference is that in the SWIMA Request attribute the SWIMA-PV provides an EID other than 0. (An EID value of 0 in a SWIMA Request represents a request for an inventory.) When the SWIMA-PC receives such a request, instead of identifying records from the endpoint's Software Inventory Evidence Collection, it consults its list of detected changes. The SWIMA-PC MUST add an event record to the SWIMA Response attribute for each recorded change event with an EID greater than or equal to the EID in the SWIMA Request attribute (although the targeting of requests, as described in the next paragraph, might limit this list). A list of event records MUST only contain events with EIDs that all come from the current Epoch.
SWIMA-PVは、インベントリの代わりにイベントレコードのリストを要求できる必要があります。このような交換の属性フローは、図2に示す基本フローと同じように見えます。唯一の違いは、SWIMA要求属性でSWIMA-PVが0以外のEIDを提供することです（SWIMA要求ではEID値0です）。 SWIMA-PCがエンドポイントのソフトウェアインベントリエビデンスコレクションからレコードを識別する代わりに、そのようなリクエストを受信すると、検出された変更のリストを調べます。 SWIMA-PCは、SWIMA要求属性のEID以上のEIDを持つ、記録された各変更イベントのSWIMA応答属性にイベントレコードを追加する必要があります（ただし、次の段落で説明するように、要求の対象指定は制限される場合があります）このリスト）。イベントレコードのリストには、すべて現在のエポックに由来するEIDを持つイベントのみを含める必要があります。
SWIMA-PVs can target requests for event records by including one or more Software Identifiers, as described in Section 3.5, in the SWIMA Request that requests an event record list. A targeted request for event records is used to indicate that only events affecting software that matches one of the provided Software Identifiers are to be returned. Specifically, in response to a targeted request for event records, the SWIMA-PC MUST exclude any event records that are less than the indicated EID (within the current EID Epoch) and exclude any event records where the affected software does not match one of the provided Software Identifiers. This might mean that the resulting list of event records sent in the response attribute does not provide a continuous sequence of EIDs. Both SWIMA-PCs and SWIMA-PVs MUST support targeted requests for event records.
SWIMA-PVは、セクション3.5で説明されているように、イベントレコードリストをリクエストするSWIMAリクエストに1つ以上のソフトウェア識別子を含めることで、イベントレコードのリクエストをターゲットにできます。イベントレコードの対象を絞った要求は、提供されたソフトウェア識別子のいずれかに一致するソフトウェアに影響を与えるイベントのみが返されることを示すために使用されます。具体的には、イベントレコードの対象を絞った要求に応じて、SWIMA-PCは、指定されたEID（現在のEIDエポック内）未満のイベントレコードを除外し、影響を受けるソフトウェアがいずれかと一致しないイベントレコードを除外する必要があります。提供されたソフトウェア識別子。これは、response属性で送信されたイベントレコードの結果リストが、EIDの連続したシーケンスを提供しないことを意味する場合があります。 SWIMA-PCとSWIMA-PVはどちらも、イベントレコードの対象を絞った要求をサポートする必要があります。
Over time, a SWIMA-PC might record a large number of change events. If a SWIMA-PV requests all change events covering a long period of time, the resulting SWIMA Response attribute might be extremely large, especially if the SWIMA-PV requests the inclusion of Software Inventory Evidence Records in the response. In the case that the resulting attribute is too large to send (because it exceeds either (1) the 4 GB attribute size limit imposed by the PA-TNC specification or (2) some smaller size limit imposed on the SWIMA-PC), the SWIMA-PC MAY send a partial list of event records back to the SWIMA-PV.
時間の経過とともに、SWIMA-PCは多数の変更イベントを記録する可能性があります。 SWIMA-PVが長期間にわたるすべての変更イベントを要求する場合、特にSWIMA-PVが応答にソフトウェアインベントリエビデンスレコードを含めることを要求する場合、結果のSWIMA応答属性は非常に大きくなる可能性があります。結果の属性が大きすぎて送信できない場合（（1）PA-TNC仕様による4 GBの属性サイズ制限、または（2）SWIMA-PCでのいくつかの小さなサイズ制限）を超えているため、 SWIMA-PCは、イベントレコードの部分的なリストをSWIMA-PVに送信する場合があります。
The generation of a partial list of events in a SWIMA Response attribute requires the SWIMA-PC to identify a "consulted range" of EIDs. A consulted range is the set of event records that are examined for inclusion in the SWIMA Response attribute and that are included in that attribute if applicable. Recall that if a SWIMA Request is targeted, only event records that involve the indicated software would be applicable. (See Section 3.5 for more on targeted requests.) If a request is not targeted, all event records in the consulted range are applicable and are included in the SWIMA Response attribute.
SWIMA応答属性でイベントの部分的なリストを生成するには、SWIMA-PCがEIDの「コンサルトされる範囲」を識別する必要があります。調査範囲は、SWIMA応答属性に含まれるかどうかが調べられ、該当する場合はその属性に含まれるイベントレコードのセットです。 SWIMAリクエストがターゲットの場合、指定されたソフトウェアを含むイベントレコードのみが適用可能であることを思い出してください。 （ターゲットを絞ったリクエストの詳細については、セクション3.5を参照してください。）リクエストがターゲットを絞っていない場合、問い合わせ範囲内のすべてのイベントレコードが適用可能で、SWIMA応答属性に含まれます。
The lower bound of the consulted range MUST be the EID provided in the SWIMA Request. (Recall that a SWIMA-PV indicates a request for event records by providing a non-zero EID value in the SWIMA Request. See Section 3.7.4.) The upper bound of the consulted range is the EID of the latest event record (as ordered by EID values) that is included in the SWIMA Response attribute if it is applicable to the request. The EID of this last event record is called the "Last Consulted EID". The SWIMA-PC chooses this Last Consulted EID based on the size of the event record list it is willing to provide to the SWIMA-PV.
参照される範囲の下限は、SWIMAリクエストで提供されるEIDである必要があります。 （SWIMA-PVは、SWIMAリクエストでゼロ以外のEID値を提供することにより、イベントレコードのリクエストを示します。セクション3.7.4を参照してください。）調べられる範囲の上限は、最新のイベントレコードのEIDです（リクエストに適用できる場合は、SWIMAレスポンス属性に含まれるEID値で並べ替えられます）。この最後のイベントレコードのEIDは、「最後に参照されたEID」と呼ばれます。 SWIMA-PCは、SWIMA-PVに提供する予定のイベントレコードリストのサイズに基づいて、この最後に参照されたEIDを選択します。
A partial result list MUST include all applicable event records within the consulted range. This means that for any applicable event record (i.e., any event record in a non-targeted request or any event record associated with software matching a requested Software Identifier in a targeted request) whose EID is greater than or equal to the EID provided in the SWIMA Request and whose EID is less than or equal to the Last Consulted EID, that event record MUST be included in the SWIMA Response conveying this partial list of event records. This ensures that every partial list of event records is always complete within its indicated range. Remember that for targeted requests, "complete" doesn't mean that all EIDs between the range endpoints are present -- only that every matching EID between the range endpoints is included.
部分的な結果リストには、相談した範囲内のすべての該当するイベントレコードを含める必要があります。つまり、該当するイベントレコード（つまり、非対象リクエストのイベントレコード、または対象リクエストのリクエストされたソフトウェア識別子と一致するソフトウェアに関連付けられたイベントレコード）のEIDが、 SWIMAリクエストで、EIDが最後に参照されたEID以下である場合、そのイベントレコードは、このイベントレコードの部分的なリストを伝えるSWIMAレスポンスに含まれている必要があります。これにより、イベントレコードのすべての部分的なリストが、指定された範囲内で常に完全になります。ターゲットリクエストの場合、「完全」とは、範囲のエンドポイント間のすべてのEIDが存在することを意味するのではなく、範囲のエンドポイント間で一致するすべてのEIDが含まれることを思い出してください。
In addition to the EID Epoch and Last EID fields that are present in all SWIMA Responses, all SWIMA Response attributes that convey event records include a Last Consulted EID field. Note that if responding to a targeted SWIMA Request, the SWIMA Response attribute might not contain the event record whose EID matches the Last Consulted EID value. For example, that record might have been deemed inapplicable because it did not match the specified list of Software Identifiers in the SWIMA Request.
すべてのSWIMA応答に存在するEID EpochおよびLast EIDフィールドに加えて、イベントレコードを伝達するすべてのSWIMA応答属性には、Last Consulted EIDフィールドが含まれます。対象のSWIMA要求に応答する場合、SWIMA応答属性には、EIDが最後に参照されたEID値と一致するイベントレコードが含まれていない可能性があることに注意してください。たとえば、そのレコードは、SWIMAリクエストで指定されたソフトウェア識別子のリストと一致しなかったため、該当しないと見なされた可能性があります。
If a SWIMA-PV receives a SWIMA Response attribute where the Last EID and Last Consulted EID fields are identical, the SWIMA-PV knows that it has received a result list that is complete, given the parameters of the request, up to the present time.
SWIMA-PVが、Last EIDフィールドとLast Consulted EIDフィールドが同じであるSWIMA応答属性を受信した場合、SWIMA-PVは、要求のパラメーターを指定すると、現時点までに完了した結果リストを受信したことを認識します。 。
On the other hand, if the Last EID is greater than the Last Consulted EID, the SWIMA-PV has received a partial result list. (The Last Consulted EID MUST NOT exceed the Last EID.) In this case, if the SWIMA-PV wishes to try to collect the rest of the partially delivered result list, it then sends a new SWIMA Request whose EID is one greater than the Last Consulted EID in the preceding response. Doing this causes the SWIMA-PC to generate another SWIMA Response attribute containing event records where the earliest reported event record is the one immediately after the event record with the Last Consulted EID (since EIDs are assigned sequentially). By repeating this process until it receives a SWIMA Response where the Last EID and Last Consulted EID are equal, the SWIMA-PV is able to collect all event records over a given range, even if the complete set of event records would be too large to deliver via a single attribute.
一方、Last EIDがLast Consulted EIDより大きい場合、SWIMA-PVは部分的な結果リストを受信しています。 （最後に参照されたEIDは、最後のEIDを超えてはなりません。）この場合、SWIMA-PVが部分的に配信された結果リストの残りを収集しようとすると、EIDが1より大きい新しいSWIMAリクエストを送信します。前の応答の最後に参照されたEID。これを行うと、SWIMA-PCはイベントレコードを含む別のSWIMA応答属性を生成します。最も早く報告されたイベントレコードは、最後に参照されたEIDを持つイベントレコードの直後のものです（EIDが順番に割り当てられるため）。最後のEIDと最後に参照されたEIDが等しいSWIMA応答を受信するまでこのプロセスを繰り返すことにより、SWIMA-PVは、イベントレコードの完全なセットが大きすぎても、指定された範囲のすべてのイベントレコードを収集できます。単一の属性を介して配信します。
Implementers need to be aware that a SWIMA Request might specify an EID that is greater than the EID of the last event recorded by a SWIMA-PC. In accordance with the behaviors described in Section 3.7.4, a SWIMA-PC MUST respond to such a request with a SWIMA Response attribute that contains zero event records. This is because the SWIMA-PC has recorded no event records with EIDs greater than or equal to the EID in the SWIMA Request. In such a case, the Last Consulted EID field MUST be set to the same value as the Last EID field in this SWIMA Response attribute. This case is called out because the consulted range on a SWIMA-PC in such a situation is a negative range, where the "first" EID in the range (provided in the SWIMA Request) is greater than the "last" EID in the range (this being the EID of the last recorded event on the SWIMA-PC). Implementers need to ensure that SWIMA-PCs do not experience problems in such a circumstance.
実装者は、SWIMAリクエストがSWIMA-PCによって記録された最後のイベントのEIDより大きいEIDを指定する可能性があることに注意する必要があります。セクション3.7.4で説明されている動作に従って、SWIMA-PCは、ゼロのイベントレコードを含むSWIMA応答属性でそのような要求に応答する必要があります。これは、SWIMA-PCがEIDがSWIMAリクエストのEID以上のイベントレコードを記録していないためです。このような場合、Last Consulted EIDフィールドは、このSWIMA Response属性のLast EIDフィールドと同じ値に設定する必要があります。このような状況でSWIMA-PCで調べられる範囲は負の範囲であり、範囲内の（最初の）EID（SWIMAリクエストで指定）が範囲内の「最後の」EIDより大きいため、このケースが呼び出されます。 （これはSWIMA-PCで最後に記録されたイベントのEIDです）。実装者は、SWIMA-PCがこのような状況で問題を経験しないようにする必要があります。
Note that this specification only supports the returning of partial results when returning event records. There is no way to return a partial inventory list under this specification.
この仕様は、イベントレコードを返すときに部分的な結果を返すことのみをサポートすることに注意してください。この仕様では、部分的な在庫リストを返す方法はありません。
Since EIDs are sequential within an Epoch, if a SWIMA-PV's list of event records contains gaps in the EID values within a single Epoch, the SWIMA-PV knows that there are events that it has not accounted for. The SWIMA-PV can request either (1) a new event list to collect the missing events or (2) a full inventory to resync its understanding of the state of the endpoint's Software Inventory Evidence Collection. In either case, after the SWIMA-PV's record of the endpoint's Software Inventory Evidence Collection has been updated, the SWIMA-PV can record the new latest EID value and track events normally from that point on.
EIDはエポック内で連続しているため、SWIMA-PVのイベントレコードのリストに単一のエポック内のEID値のギャップが含まれている場合、SWIMA-PVは、考慮されていないイベントがあることを認識します。 SWIMA-PVは、（1）不足しているイベントを収集するための新しいイベントリスト、または（2）エンドポイントのソフトウェアインベントリエビデンスコレクションの状態の理解を再同期するためのフルインベントリのいずれかを要求できます。どちらの場合も、エンドポイントのソフトウェアインベントリエビデンスコレクションのSWIMA-PVのレコードが更新された後、SWIMA-PVは新しい最新のEID値を記録し、その時点から通常のイベントを追跡できます。
If the SWIMA-PV receives any attribute from a SWIMA-PC where the EID Epoch differs from the EID Epoch that was used previously, then the SWIMA-PV or any entity using this information to track the endpoint's Software Inventory Evidence Collection knows that there is a discontinuity in its understanding of the endpoint's state. To move past this discontinuity and reestablish a current understanding of the state of the endpoint's Software Inventory Evidence Collection, the SWIMA-PV needs to receive a full inventory from the endpoint. The SWIMA-PV cannot be brought in sync with the endpoint's state through the collection of any set of event records in this situation. This is because it is not possible to account for all events on the SWIMA-PC since the previous Epoch was used: there is no way to query for EIDs from a previous Epoch. Once the SWIMA-PV has received a full inventory for the new Epoch, the SWIMA-PV records the latest EID reported in this new Epoch and can track further events normally.
SWIMA-PVが、以前に使用されたEIDエポックとEIDエポックが異なるSWIMA-PCから属性を受信した場合、SWIMA-PVまたはこの情報を使用してエンドポイントのソフトウェアインベントリエビデンスコレクションを追跡するエンティティは、エンドポイントの状態の理解の不連続。この不連続性を乗り越えて、エンドポイントのソフトウェアインベントリエビデンスコレクションの状態の現在の理解を再確立するには、SWIMA-PVがエンドポイントから完全なインベントリを受信する必要があります。この状況では、一連のイベントレコードを収集して、SWIMA-PVをエンドポイントの状態と同期させることはできません。これは、以前のエポックが使用されていたため、SWIMA-PC上のすべてのイベントを考慮することができないためです。以前のエポックからEIDを照会する方法はありません。 SWIMA-PVが新しいエポックの完全なインベントリを受信すると、SWIMA-PVはこの新しいエポックで報告された最新のEIDを記録し、通常はさらにイベントを追跡できます。
A SWIMA-PC MUST NOT report events with EIDs from any Epoch other than the current EID Epoch. The SWIMA-PC MAY choose to purge all event records from a previous Epoch from memory after an Epoch change. Alternately, the SWIMA-PC MAY choose to retain some event records from a previous EID Epoch and assign them new EIDs in the current Epoch. However, in the case where a SWIMA-PC chooses the latter option it MUST ensure that the order of events according to their EIDs is unchanged and that there is no coverage gap between the first retained event recorded during the previous Epoch (now reassigned with an EID in the current Epoch) and the first event recorded during the current Epoch. In particular, the SWIMA-PC MUST ensure that all change events that occurred after the last recorded event from the previous Epoch are known and recorded. (This might not be possible if the Epoch change is due to state corruption on the SWIMA-PC.) A SWIMA-PC might choose to reassign EIDs to records from a preceding Epoch to create a "sliding window" of events, where each Epoch change represents a shift in the window of available events.
SWIMA-PCは、現在のEIDエポック以外のエポックからのEIDを持つイベントを報告してはなりません。 SWIMA-PCは、エポックの変更後に、以前のエポックからのすべてのイベントレコードをメモリからパージすることを選択できます。あるいは、SWIMA-PCは、以前のEIDエポックからのいくつかのイベントレコードを保持し、それらに現在のエポックで新しいEIDを割り当てることを選択する場合があります。ただし、SWIMA-PCが後者のオプションを選択する場合は、EIDに従ってイベントの順序が変更されていないこと、および前のエポック中に記録された最初の保持されたイベントの間にカバレッジギャップがないことを保証する必要があります（現在、現在のエポックのEID）、および現在のエポック中に記録された最初のイベント。特に、SWIMA-PCは、前のエポックから最後に記録されたイベントの後に発生したすべての変更イベントが認識され、記録されていることを確認する必要があります。 （エポックの変更がSWIMA-PCの状態の破損が原因である場合、これは不可能である可能性があります。）SWIMA-PCは、前のエポックのレコードにEIDを再割り当てして、イベントの「スライディングウィンドウ」を作成することを選択できます。変化は、利用可能なイベントのウィンドウの変化を表します。
In the case where a SWIMA-PC suffers a crash and loses track of its current EID Epoch or current EID, then it MUST generate a new EID Epoch value and begin assigning EIDs within that Epoch. In this case, the SWIMA-PC MUST purge all event records from before the crash, as it cannot ensure that there is not a gap between the last of those records and the next detected event. The process for generating a new EID Epoch MUST minimize the possibility that the newly generated EID Epoch is the same as a previously used EID Epoch.
SWIMA-PCがクラッシュし、現在のEIDエポックまたは現在のEIDを追跡できなくなった場合、新しいEIDエポック値を生成し、そのエポック内でEIDの割り当てを開始する必要があります。この場合、SWIMA-PCは最後のレコードと次の検出されたイベントの間にギャップがないことを保証できないため、クラッシュ前のすべてのイベントレコードをパージする必要があります。新しいEIDエポックを生成するプロセスは、新しく生成されたEIDエポックが以前に使用されたEIDエポックと同じである可能性を最小限に抑える必要があります。
The SWIMA-PV will normally never receive an attribute indicating that the latest EID is less than the latest EID reported in a previous attribute within the same EID Epoch. If this occurs, the SWIMA-PC has suffered an error of some kind, possibly indicative of at least partial corruption of its event log. In this case, the SWIMA-PV MUST treat the situation as if there was a change in Epoch and treat any local copy of the endpoint's Software Inventory Evidence Collection as being out of sync until a full inventory can be reported by the SWIMA-PC. The SWIMA-PV SHOULD log the occurrence so the SWIMA-PC can be examined to ensure that it is now operating properly.
SWIMA-PVは通常、最新のEIDが同じEIDエポック内の以前の属性で報告された最新のEIDより小さいことを示す属性を受信しません。これが発生する場合、SWIMA-PCに何らかのエラーが発生しており、イベントログが少なくとも部分的に破損している可能性があります。この場合、SWIMA-PVは、エポックに変更があったかのように状況を扱い、完全なインベントリがSWIMA-PCによって報告されるまで、エンドポイントのソフトウェアインベントリエビデンスコレクションのローカルコピーを同期外れとして扱う必要があります。 SWIMA-PVは発生をログに記録する必要があるため、SWIMA-PCを調べて、SWIMA-PCが正常に動作していることを確認できます。
Thus far, all attribute exchanges discussed assume that a SWIMA-PV sent a SWIMA Request attribute and the SWIMA-PC is providing a direct response to that request. SWIMA also supports the ability of a SWIMA-PC to send a SWIMA Response to the SWIMA-PV in response to observed changes in the endpoint's Software Inventory Evidence Collection, instead of in direct response to a SWIMA Request. An agreement by a SWIMA-PC to send content when certain changes to the endpoint's Software Inventory Evidence Collection are detected is referred to in this specification as a "subscription", and the SWIMA-PV that receives this content is said to be "subscribed to" the given SWIMA-PC. All SWIMA-PCs and SWIMA-PVs MUST support the use of subscriptions.
これまでに説明したすべての属性交換では、SWIMA-PVがSWIMA要求属性を送信し、SWIMA-PCがその要求に直接応答していると想定しています。 SWIMAは、SWIMA要求に直接応答するのではなく、エンドポイントのソフトウェアインベントリエビデンスコレクションで観察された変更に応答してSWIMA-PVにSWIMA応答を送信するSWIMA-PCの機能もサポートします。エンドポイントのソフトウェアインベントリエビデンスコレクションに対する特定の変更が検出されたときにコンテンツを送信するというSWIMA-PCによる合意は、この仕様では「サブスクリプション」と呼ばれ、このコンテンツを受信するSWIMA-PVは「サブスクライブ済み」と呼ばれます"指定されたSWIMA-PC。すべてのSWIMA-PCおよびSWIMA-PVはサブスクリプションの使用をサポートする必要があります。
A SWIMA-PV establishes a subscription on a particular SWIMA-PC by sending a SWIMA Request attribute with the Subscribe flag set. The SWIMA Request attribute is otherwise identical to the SWIMA Requests discussed in previous sections. Specifically, such a SWIMA Request might or might not request the inclusion of Software Inventory Evidence Records, might or might not be targeted, and might request change event records or endpoint inventory. Assuming that no error is encountered, a SWIMA-PC MUST send a SWIMA Response attribute in direct response to this SWIMA Request attribute, just as if the Subscribe flag was not set. As such, the attribute exchange that establishes a new subscription in a SWIMA-PC has the same flow as the flow seen in the previous attribute exchanges, as depicted in Figure 2. If the SWIMA-PV does not receive a PA-TNC Error attribute (as described in Sections 3.9 and 5.15) in response to its subscription request, the subscription has been successfully established on the SWIMA-PC. The SWIMA Request attribute that establishes a new subscription is referred to as the "establishing request" for that subscription.
SWIMA-PVは、Subscribeフラグが設定されたSWIMA要求属性を送信することにより、特定のSWIMA-PCでサブスクリプションを確立します。その他の点では、SWIMA要求属性は、前のセクションで説明したSWIMA要求と同じです。具体的には、そのようなSWIMA要求は、ソフトウェアインベントリエビデンスレコードの包含を要求する場合としない場合があり、対象となる場合とそうでない場合があり、変更イベントレコードまたはエンドポイントインベントリを要求する場合があります。エラーが発生しないと仮定すると、SWIMA-PCは、SWIMA応答属性をこのSWIMA要求属性に直接応答して送信する必要があります。これは、Subscribeフラグが設定されていない場合と同様です。そのため、図2に示すように、SWIMA-PCで新しいサブスクリプションを確立する属性交換のフローは、前の属性交換でのフローと同じです。SWIMA-PVがPA-TNCエラー属性を受信しない場合（セクション3.9および5.15で説明されているように）サブスクリプション要求に応答して、サブスクリプションがSWIMA-PCで正常に確立されました。新しいサブスクリプションを確立するSWIMA要求属性は、そのサブスクリプションの「確立要求」と呼ばれます。
When a subscription is established, it is assigned a Subscription ID value. The Subscription ID is equal to the value of the Request ID of the establishing request. (For more about Request IDs, see Section 5.5.)
サブスクリプションが確立されると、サブスクリプションID値が割り当てられます。サブスクリプションIDは、確立要求の要求IDの値と同じです。 （リクエストIDの詳細は、5.5項を参照してください。）
A SWIMA-PC MUST have the ability to record and support at least 8 simultaneous subscriptions and SHOULD have the ability to support more than this. These subscriptions might all come from a single SWIMA-PV, might all be from different SWIMA-PVs (residing on the same or different NEA Servers), or might be a mix. In the case that a SWIMA-PC receives a subscription request but is unable to support an additional subscription, it MUST respond to the request with a PA-TNC Error attribute with error code SWIMA_SUBSCRIPTION_DENIED_ERROR.
SWIMA-PCは、少なくとも8つの同時サブスクリプションを記録およびサポートする機能を持っている必要があり、SHOULDはこれ以上をサポートする機能を持っている必要があります。これらのサブスクリプションはすべて、単一のSWIMA-PVからのものである場合もあれば、異なるSWIMA-PV（同じまたは異なるNEAサーバー上に存在する）からのものである場合もあれば、混在している場合もあります。 SWIMA-PCがサブスクリプション要求を受信したが、追加のサブスクリプションをサポートできない場合は、エラーコードSWIMA_SUBSCRIPTION_DENIED_ERRORを含むPA-TNCエラー属性で要求に応答する必要があります。
A SWIMA-PV MUST have the ability to record and support at least 256 simultaneous subscriptions and SHOULD have the ability to support more than this. Any number of these subscriptions might be to the same SWIMA-PC, and any number of these subscriptions might be to different SWIMA-PCs. In the latter case, some of these SWIMA-PCs might share a single endpoint, while others might be on different endpoints.
SWIMA-PVは、少なくとも256の同時サブスクリプションを記録およびサポートする機能を持っている必要があり、SHOULDはこれ以上の機能をサポートする必要があります。これらのサブスクリプションはいくつでも同じSWIMA-PCに対するものである可能性があり、これらのサブスクリプションはいくつでも異なるSWIMA-PCに対するものである可能性があります。後者の場合、これらのSWIMA-PCのいくつかは単一のエンドポイントを共有する可能性がありますが、他は異なるエンドポイント上にある可能性があります。
The SWIMA-PC MUST record each accepted subscription along with the identity of the party to whom attributes are to be pushed. This identity includes two parts:
SWIMA-PCは、受け入れられた各サブスクリプションと、属性がプッシュされるパーティのIDを記録する必要があります。このアイデンティティには2つの部分があります。
o An identifier for the PB-TNC session between the Posture Broker Server on a NEA Server and the Posture Broker Client on the endpoint. This identifier is called the "Connection ID"
o NEAサーバーのポスチャブローカーサーバーとエンドポイントのポスチャーブローカークライアント間のPB-TNCセッションの識別子。この識別子は「接続ID」と呼ばれます
o The Posture Validator Identifier for the SWIMA-PV that made the subscription request
o サブスクリプション要求を行ったSWIMA-PVのポスチャ検証識別子
The Posture Validator Identifier is provided in the field of the same name in the PB-PA message that encapsulates the subscription request attribute (Section 4.5 of [RFC5793]), and this information is passed along to NEA Posture Collectors (Section 3.3 of [RFC5792]). The Connection ID is a value local to a particular endpoint's Posture Broker Client that identifies an ongoing session between a specific Posture Broker Client and a specific Posture Broker Server. Posture Broker Clients and Posture Broker Servers need to be capable of supporting multiple simultaneous sessions, so they already need a way to locally distinguish each ongoing session. (See Section 3.1 of [RFC5793].) A Posture Broker Client needs to assign each session at a given time its own Connection ID that lasts for the life of that session. Connection IDs only need to be unique among the Connection IDs of simultaneously occurring sessions on that endpoint. This Connection ID needs to be exposed to the SWIMA-PC, and the SWIMA-PC needs to be informed when the Connection ID is unbound due to the closure of that connection.
Posture Validator Identifierは、サブスクリプション要求属性をカプセル化するPB-PAメッセージの同じ名前のフィールドに提供され（[RFC5793]のセクション4.5）、この情報はNEA Posture Collectors（[RFC5792のセクション3.3]に渡されます。 ]）。接続IDは、特定のエンドポイントのポスチャブローカークライアントにローカルな値であり、特定のポスチャブローカークライアントと特定のポスチャブローカーサーバー間の進行中のセッションを識別します。ポスチャブローカークライアントとポスチャブローカーサーバーは、複数の同時セッションをサポートできる必要があるため、すでに進行中の各セッションをローカルで区別する方法が必要です。 （[RFC5793]のセクション3.1を参照してください。）Posture Brokerクライアントは、特定の時間に各セッションに、そのセッションの存続期間にわたって持続する独自の接続IDを割り当てる必要があります。接続IDは、そのエンドポイントで同時に発生するセッションの接続IDの中で一意である必要があるだけです。この接続IDはSWIMA-PCに公開する必要があり、SWIMA-PCは、その接続のクローズのために接続IDがバインド解除されたときに通知を受ける必要があります。
Likewise, SWIMA-PVs MUST record each accepted subscription for which they are the subscribing party, including the parameters of the establishing request, along with the associated Subscription ID and the identity of the SWIMA-PC that will be fulfilling the subscription. The SWIMA-PV needs to retain this information in order to correctly interpret pushed SWIMA Response attributes sent in fulfillment of the subscription. The identity of the SWIMA-PC is given in the Posture Collector Identifier [RFC5793] of the PB-PA message header in all messages from that SWIMA-PC. The SWIMA-PV has no need to record the associated connection ID of the subscription as the SWIMA-PV is only receiving, not sending, attributes once a subscription is established.
同様に、SWIMA-PVは、関連付けられたサブスクリプションIDとサブスクリプションを実行するSWIMA-PCのIDとともに、確立要求のパラメーターを含め、サブスクライブパーティである承認済みの各サブスクリプションを記録する必要があります。 SWIMA-PVは、サブスクリプションのフルフィルメントで送信されるプッシュされたSWIMA応答属性を正しく解釈するために、この情報を保持する必要があります。 SWIMA-PCのIDは、そのSWIMA-PCからのすべてのメッセージのPB-PAメッセージヘッダーのポスチャコレクタID [RFC5793]で指定されます。サブスクリプションが確立されると、SWIMA-PVは属性を受信するだけで送信しないため、SWIMA-PVはサブスクリプションの関連する接続IDを記録する必要はありません。
Subscriptions MAY be terminated at any time by the subscribing SWIMA-PV by setting the Clear Subscriptions flag in a SWIMA Request. (See Section 5.6 for more on using this flag.) In the case that a SWIMA Request with the Clear Subscriptions flag set is received, the SWIMA-PC MUST only clear subscriptions that match both the NEA Server's Connection ID and the SWIMA-PV's Posture Validator Identifier for this SWIMA Request and MUST clear all such subscriptions.
サブスクリプションは、SWIMAリクエストでClear Subscriptionsフラグを設定することにより、サブスクリプションを行うSWIMA-PVによっていつでも終了できます。 （このフラグの使用の詳細については、セクション5.6を参照してください。）サブスクリプションのクリアフラグが設定されたSWIMAリクエストが受信された場合、SWIMA-PCは、NEAサーバーの接続IDとSWIMA-PVのポスチャの両方に一致するサブスクリプションのみをクリアする必要があります。このSWIMAリクエストのバリデーター識別子。このようなサブスクリプションをすべてクリアする必要があります。
This specification does not give the SWIMA-PV the ability to terminate subscriptions individually -- all subscriptions to the SWIMA-PV are cleared when the Clear Subscriptions flag is set.
この仕様では、SWIMA-PVにサブスクリプションを個別に終了する機能はありません。SWIMA-PVへのすべてのサブスクリプションは、[サブスクリプションのクリア]フラグが設定されている場合にクリアされます。
This specification does not give the SWIMA-PC the ability to unilaterally terminate a subscription. However, if the SWIMA-PC experiences a fatal error while fulfilling a subscription, resulting in sending a PA-TNC Error attribute with error code SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR, then the subscription whose fulfillment led to the error MUST be treated as terminated by both the SWIMA-PC and the SWIMA-PV. Only the subscription experiencing the error is cancelled; other subscriptions are unaffected. See Section 3.9 for more on this error condition.
この仕様では、SWIMA-PCが一方的にサブスクリプションを終了することはできません。ただし、サブスクリプションの実行中にSWIMA-PCで致命的なエラーが発生し、エラーコードSWIMA_SUBSCRIPTION_FULFILLMENT_ERRORを含むPA-TNCエラー属性が送信された場合、エラーが発生したサブスクリプションは、両方のSWIMA-PCによって終了したものとして処理する必要があります。そしてSWIMA-PV。エラーが発生したサブスクリプションのみがキャンセルされます。他のサブスクリプションは影響を受けません。このエラー状態の詳細については、セクション3.9を参照してください。
Finally, a subscription is terminated if the connection between the SWIMA-PC and SWIMA-PV is closed. This occurs when the Connection ID used in the messages between the SWIMA-PC and the SWIMA-PV becomes unbound. Loss of this Connection ID would prevent the SWIMA-PC from sending messages in fulfillment of this subscription. As such, loss of the Connection ID necessarily forces subscription termination between the affected parties.
最後に、SWIMA-PCとSWIMA-PVの間の接続が閉じられると、サブスクリプションは終了します。これは、SWIMA-PCとSWIMA-PVの間のメッセージで使用されている接続IDがバインドされていない場合に発生します。この接続IDが失われると、SWIMA-PCはこのサブスクリプションの実行中にメッセージを送信できなくなります。そのため、接続IDが失われると、影響を受ける当事者間のサブスクリプションが強制的に終了されます。
A SWIMA-PV can request that a SWIMA-PC report the list of active subscriptions for which the SWIMA-PV is the subscriber. A SWIMA-PV can use this capability to recover lost information about active subscriptions. A SWIMA-PV can also use this capability to verify that a SWIMA-PC has not forgotten any of its subscriptions. The latter is especially useful in cases where a SWIMA-PC does not send any attributes in fulfillment of a given subscription for a long period of time. The SWIMA-PV can check the list of active subscriptions on the SWIMA-PC and verify whether the inactivity is due to (1) a lack of reportable events or (2) the SWIMA-PC forgetting its obligations to fulfill a given subscription.
SWIMA-PVは、SWIMA-PVがサブスクライバーであるアクティブなサブスクリプションのリストをSWIMA-PCに報告するよう要求できます。 SWIMA-PVはこの機能を使用して、アクティブなサブスクリプションに関する失われた情報を回復できます。 SWIMA-PVはこの機能を使用して、SWIMA-PCがサブスクリプションを忘れていないことを確認することもできます。後者は、SWIMA-PCが長期間にわたって特定のサブスクリプションの履行において属性を送信しない場合に特に役立ちます。 SWIMA-PVは、SWIMA-PC上のアクティブなサブスクリプションのリストをチェックし、非アクティブが（1）報告可能なイベントの欠如によるものか、または（2）SWIMA-PCが特定のサブスクリプションを実行する義務を忘れたことによるものかを確認できます。
A SWIMA-PV requests a list of its subscriptions on a given SWIMA-PC by sending that SWIMA-PC a Subscription Status Request. The SWIMA-PC MUST then respond with a Subscription Status Response (or a PA-TNC Error if an error condition is experienced). The Subscription Status Response MUST contain one subscription record for each of the active subscriptions for which the SWIMA-PV is the subscribing party.
SWIMA-PVは、サブスクリプションステータス要求を送信することにより、特定のSWIMA-PC上のサブスクリプションのリストを要求します。 SWIMA-PCは、サブスクリプションステータス応答（または、エラー状態が発生した場合はPA-TNCエラー）で応答する必要があります。サブスクリプションステータス応答には、SWIMA-PVがサブスクライブパーティであるアクティブなサブスクリプションごとに1つのサブスクリプションレコードが含まれている必要があります。
As noted in Section 3.6, SWIMA-PCs are required to automatically detect changes to an endpoint's Software Inventory Evidence Collection in near real time. For every active subscription, the SWIMA-PC MUST send an attribute to the subscribed SWIMA-PV whenever a change to relevant records is detected within the endpoint's Software Inventory Evidence Collection. Such an attribute is said to be sent "in fulfillment of" the given subscription, and any such attribute MUST include that subscription's Subscription ID. If the establishing request for that subscription was a targeted request, then only records that match the Software Identifiers provided in that establishing request are considered relevant. Otherwise (i.e., for non-targeted requests), any record is considered relevant for this purpose. Figure 3 shows a sample attribute exchange where a subscription is established and then attributes are sent from the SWIMA-PC in fulfillment of the established subscription.
セクション3.6で述べたように、SWIMA-PCは、ほぼリアルタイムでエンドポイントのソフトウェアインベントリエビデンスコレクションへの変更を自動的に検出する必要があります。すべてのアクティブなサブスクリプションについて、エンドポイントのソフトウェアインベントリエビデンスコレクション内で関連するレコードへの変更が検出された場合は常に、SWIMA-PCがサブスクライブしたSWIMA-PVに属性を送信する必要があります。そのような属性は、与えられたサブスクリプションの「履行中」に送信されると言われ、そのような属性には、そのサブスクリプションのサブスクリプションIDを含める必要があります。そのサブスクリプションの確立要求がターゲット要求であった場合、その確立要求で提供されたソフトウェア識別子と一致するレコードのみが関連すると見なされます。それ以外の場合（つまり、対象外のリクエストの場合）、すべてのレコードがこの目的に関連すると見なされます。図3は、サブスクリプションが確立され、確立されたサブスクリプションの実行時にSWIMA-PCから属性が送信されるサンプルの属性交換を示しています。
+-------------+ +--------------+
| SWIMA-PC | | SWIMA-PV | Time
+-------------+ +--------------+ |
| | |
|<----------SWIMA Request-----------| |
| | |
|-----------SWIMA Response--------->| |
| | |
. . .
. . .
. . .
<Change Event>| | |
|----------SWIMA Response---------->| |
| | |
. . .
. . .
. . .
<Change Event>| | |
|----------SWIMA Response---------->| |
| | V
Figure 3: Subscription Establishment and Fulfillment
図3：サブスクリプションの確立とフルフィルメント
The contents of an attribute sent in fulfillment of a subscription depend on the parameters provided in the establishing request for that subscription. Specifically, the attribute sent in fulfillment of a subscription has the same attribute type as would a direct response to the establishing request. For example, if the establishing request stipulated a response that contained an event record list that included Software Inventory Evidence Records, all attributes sent in fulfillment of this subscription will also consist of event record lists with Software Inventory Evidence Records. As such, all SWIMA Responses displayed in the exchange depicted in Figure 3 are the same attribute type. A SWIMA Response generated in fulfillment of an active subscription MUST be a valid SWIMA Response attribute according to all the rules outlined in the preceding sections. In other words, an attribute constructed in fulfillment of a subscription will look the same as an attribute sent in direct response to an explicit request from a SWIMA-PV that had the same request parameters and that arrived immediately after the given change event. There are a few special rules that expand on this guideline, as discussed in Sections 3.8.5.1 through 3.8.5.5.
サブスクリプションのフルフィルメントで送信される属性の内容は、そのサブスクリプションの確立要求で提供されるパラメーターによって異なります。具体的には、サブスクリプションのフルフィルメントで送信される属性は、確立要求への直接応答と同じ属性タイプを持っています。たとえば、確立要求がソフトウェアインベントリエビデンスレコードを含むイベントレコードリストを含む応答を規定している場合、このサブスクリプションのフルフィルメントで送信されるすべての属性も、ソフトウェアインベントリエビデンスレコードを含むイベントレコードリストで構成されます。そのため、図3に示す交換で表示されるすべてのSWIMA応答は同じ属性タイプです。アクティブなサブスクリプションのフルフィルメントで生成されたSWIMAレスポンスは、前のセクションで説明したすべてのルールに従って、有効なSWIMAレスポンス属性である必要があります。つまり、サブスクリプションのフルフィルメントで構築された属性は、同じリクエストパラメータがあり、指定された変更イベントの直後に到着したSWIMA-PVからの明示的なリクエストに直接応答して送信された属性と同じように見えます。セクション3.8.5.1〜3.8.5.5で説明するように、このガイドラインを拡張するいくつかの特別なルールがあります。
In the case that a SWIMA-PV subscribes to a SWIMA-PC and requests an inventory attribute whenever changes are detected (i.e., the EID in the establishing request is 0), then the SWIMA-PC MUST send the requested inventory whenever a relevant change is detected. (A "relevant change" is any change for non-targeted requests or a change to an indicated record in a targeted request.) Upon detection of a relevant change for an active subscription, the SWIMA-PC sends the appropriate inventory information as if it had just received the establishing request. Inventory attributes sent in fulfillment of this subscription will probably have a large amount of redundancy, as the same records are likely to be present in each of these SWIMA attributes. The role of an inventory subscription is not to report records just for the items that changed -- that is the role of a subscription that reports events (see Section 3.8.5.2). A SWIMA-PC MUST NOT exclude a record from an attribute sent in fulfillment of an inventory subscription simply because that record was not involved in the triggering event (although a record might be excluded for other reasons, such as if the subscription is targeted; see Section 3.8.5.3).
SWIMA-PVがSWIMA-PCにサブスクライブし、変更が検出されるたびにインベントリ属性を要求する（つまり、確立要求のEIDが0である）場合、SWIMA-PCは関連する変更があるたびに要求されたインベントリを送信する必要があります。が検出されました。 （「関連する変更」とは、対象外の要求に対する変更または対象となる要求内の指定されたレコードへの変更です。）アクティブなサブスクリプションに関連する変更が検出されると、SWIMA-PCは適切なインベントリ情報をあたかも送信します。確立のリクエストを受け取ったところです。このサブスクリプションのフルフィルメントで送信される在庫属性は、これらのSWIMA属性のそれぞれに同じレコードが存在する可能性が高いため、おそらく大量の冗長性があります。在庫サブスクリプションの役割は、変更されたアイテムのレコードのみを報告することではなく、イベントを報告するサブスクリプションの役割です（セクション3.8.5.2を参照）。 SWIMA-PCは、そのレコードがトリガーイベントに関与していなかったという理由だけで、在庫サブスクリプションのフルフィルメントで送信された属性からレコードを除外してはなりません（ただし、サブスクリプションがターゲットにされている場合など、他の理由でレコードが除外されている可能性があります。セクション3.8.5.3）。
A SWIMA-PV indicates that it wishes to establish a subscription requesting event records by providing a non-zero EID in the SWIMA Request establishing the subscription (see Section 3.7.1). However, when the SWIMA-PC constructs an attribute in fulfillment of the subscription (other than the direct response to the establishing request), it MUST only include event records for the detected change(s) that precipitated this response attribute. In other words, it MUST NOT send a complete list of all changes starting with the establishing request's EID, up through the latest change, every time a new event is detected. In effect, the EID in the establishing request is treated as being updated every time an attribute is sent in fulfillment of this subscription, such that a single event is not reported twice in fulfillment of a single subscription. As such, every SWIMA-PC MUST track the EID of the last event that triggered an attribute for the given subscription. When the next event (or set of events) is detected, the SWIMA-PC MUST only report events with EIDs after the last reported event. In the case that the EID Epoch of the SWIMA-PC changes, the SWIMA-PC MUST reset this EID tracker to zero (if the event log is completely purged) or to the new EID of the last reported retained event (if the event log is partially purged to create a "sliding window"). Doing this ensures that the SWIMA-PC continues to only send events that have not been previously reported.
SWIMA-PVは、サブスクリプションを確立するSWIMAリクエストにゼロ以外のEIDを提供することにより、イベントレコードを要求するサブスクリプションを確立することを望んでいることを示します（セクション3.7.1を参照）。ただし、SWIMA-PCがサブスクリプションの履行時に属性を構築する場合（確立要求への直接応答以外）、この応答属性を引き起こした検出された変更のイベントレコードのみを含める必要があります。言い換えると、新しいイベントが検出されるたびに、確立要求のEIDで始まり、最新の変更までのすべての変更の完全なリストを送信してはなりません（MUST NOT）。実際、確立中のリクエストのEIDは、このサブスクリプションのフルフィルメントで属性が送信されるたびに更新されるものとして扱われるため、単一のサブスクリプションのフルフィルメントで単一のイベントが2回報告されることはありません。そのため、すべてのSWIMA-PCは、特定のサブスクリプションの属性をトリガーした最後のイベントのEIDを追跡する必要があります。次のイベント（またはイベントのセット）が検出された場合、SWIMA-PCは、最後に報告されたイベントの後に、EIDを持つイベントのみを報告する必要があります。 SWIMA-PCのEIDエポックが変更された場合、SWIMA-PCはこのEIDトラッカーをゼロ（イベントログが完全に削除された場合）または最後に報告された保持イベントの新しいEID（イベントログの場合）にリセットする必要があります。 「スライディングウィンドウ」を作成するために部分的にパージされます）。これにより、SWIMA-PCは、以前に報告されていないイベントのみを送信し続けることが保証されます。
Note that while a subscription is active, the subscribing SWIMA-PV MAY make other requests for event records that overlap with events that are reported in fulfillment of a subscription. Such requests are not affected by the presence of the subscription, nor is the subscription affected by such requests. In other words, a given request will get the same results back whether or not there was a subscription. Likewise, an attribute sent in fulfillment of a subscription will contain the same information whether or not other requests had been received from the SWIMA-PV.
サブスクリプションがアクティブである間、サブスクライブするSWIMA-PVは、サブスクリプションの実行で報告されるイベントと重複するイベントレコードに対して他のリクエストを行う場合があります。このようなリクエストは、サブスクリプションの存在による影響を受けず、サブスクリプションもそのようなリクエストによる影響を受けません。つまり、サブスクリプションがあったかどうかに関係なく、指定されたリクエストは同じ結果を返します。同様に、サブスクリプションのフルフィルメントで送信される属性には、他のリクエストがSWIMA-PVから受信されたかどうかに関係なく、同じ情報が含まれます。
A SWIMA-PV needs to pay attention to the EID Epoch in these attributes, as changes in the Epoch might create discontinuities in the SWIMA-PV's understanding of the endpoint's Software Inventory Evidence Collection state, as discussed in Section 3.7.6. In particular, once the EID Epoch changes, a SWIMA-PV is unable to have confidence that it has a correct understanding of the state of an endpoint's Software Inventory Evidence Collection until after the SWIMA-PV collects a complete inventory.
セクション3.7.6で説明するように、エポックの変更により、エンドポイントのソフトウェアインベントリエビデンスコレクションの状態に関するSWIMA-PVの理解に不連続が生じる可能性があるため、SWIMA-PVはこれらの属性のEIDエポックに注意を払う必要があります。特に、EIDエポックが変更されると、SWIMA-PVが完全なインベントリを収集するまで、SWIMA-PVはエンドポイントのソフトウェアインベントリエビデンスコレクションの状態を正しく理解しているとは確信できません。
SWIMA-PCs MAY send partial lists of event records in fulfillment of a subscription. (See Section 3.7.5 for more on partial lists of event records.) In the case that a SWIMA-PC sends a partial list of event records in fulfillment of a subscription, it MUST immediately send the next consecutive partial list and continue doing so until it has sent the equivalent of the complete list of event records. In other words, if the SWIMA-PC sends a partial list, it does not wait for another change event to send another SWIMA Response; rather, it continues sending SWIMA Responses until it has sent all event records that would have been included in a complete fulfillment of the subscription. Note that the direct response to the establishing request is not considered to be sent in fulfillment of a subscription. However, in this case the SWIMA-PC MUST treat the presence of unreported events as a triggering event for pushing additional messages in fulfillment of the newly established subscription. As such, the net effect is that if the direct response to the establishing request (i.e., the Subscription Fulfillment flag is unset) is partial, the SWIMA-PC will immediately follow this with additional attributes (with the Subscription Fulfillment flag set) until the complete set of events has been sent to the SWIMA-PV.
SWIMA-PCは、サブスクリプションの実行時にイベントレコードの部分的なリストを送信する場合があります。 （イベントレコードの部分リストの詳細については、セクション3.7.5を参照してください。）SWIMA-PCがサブスクリプションの履行でイベントレコードの部分リストを送信する場合、SWIMA-PCはすぐに次の連続した部分リストを送信して送信を継続する必要があります。イベントレコードの完全なリストに相当するものが送信されるまで。つまり、SWIMA-PCが部分的なリストを送信する場合、別の変更イベントが別のSWIMA応答を送信するのを待ちません。むしろ、サブスクリプションの完全な履行に含まれるはずのすべてのイベントレコードを送信するまで、SWIMA応答を送信し続けます。確立要求への直接応答は、サブスクリプションの実行時に送信されるとは見なされないことに注意してください。ただし、この場合、SWIMA-PCは、未報告のイベントの存在を、新しく確立されたサブスクリプションの履行において追加のメッセージをプッシュするトリガーイベントとして扱う必要があります。そのため、正味の効果は、確立要求への直接応答（つまり、サブスクリプションフルフィルメントフラグが設定されていない）が部分的である場合、SWIMA-PCはすぐにこれに追従して（サブスクリプションフルフィルメントフラグが設定された）追加の属性イベントの完全なセットがSWIMA-PVに送信されました。
Subscriptions MAY be targeted to only apply to records that match a given set of Software Identifiers. In the case where changes that affect multiple records are detected -- some matching the establishing request's Software Identifiers and some not -- the attribute sent in fulfillment of the subscription MUST only include inventory or events (as appropriate) for records that match the establishing request's Software Identifiers. The SWIMA-PC MUST NOT include non-matching records in the attribute, even if those non-matching records experienced change events that were simultaneous with change events on the matching records.
サブスクリプションは、特定のソフトウェア識別子のセットと一致するレコードにのみ適用することを対象とする場合があります。複数のレコードに影響を与える変更が検出された場合（一部は確立リクエストのソフトウェア識別子と一致し、一部は一致しない）、サブスクリプションのフルフィルメントで送信される属性には、確立リクエストのレコードと一致するレコードのインベントリまたはイベント（必要に応じて）のみを含める必要がありますソフトウェア識別子。 SWIMA-PCは、一致しないレコードが一致するレコードの変更イベントと同時に発生した変更イベントを経験した場合でも、属性に一致しないレコードを含めてはなりません（MUST NOT）。
In addition, a SWIMA-PC MUST send an attribute in fulfillment of a targeted subscription only when changes to the endpoint's Software Inventory Evidence Collection impact one or more records matching the subscription's establishing request's Software Identifiers. A SWIMA-PC MUST NOT send any attribute in fulfillment of a targeted subscription based on detected changes to the endpoint's Software Inventory Evidence Collection that did not involve any of the records targeted by that subscription.
さらに、SWIMA-PCは、エンドポイントのソフトウェアインベントリエビデンスコレクションへの変更が、サブスクリプションの確立リクエストのソフトウェア識別子と一致する1つ以上のレコードに影響を与える場合にのみ、ターゲットサブスクリプションのフルフィルメントで属性を送信する必要があります。 SWIMA-PCは、エンドポイントのソフトウェアインベントリエビデンスコレクションへの検出された変更に基づいて、ターゲットサブスクリプションのフルフィルメントで属性を送信してはなりません。
A SWIMA-PV MAY establish multiple subscriptions to a given SWIMA-PC. If this is the case, it is possible that a single change event on the endpoint might require fulfillment by multiple subscriptions and that the information included in attributes that fulfill each of these subscriptions might overlap. The SWIMA-PC MUST send separate attributes for each established subscription that requires a response due to the given event. Each of these attributes MUST contain all information required to fulfill that individual subscription, even if that information is also sent in other attributes sent in fulfillment of other subscriptions at the same time. In other words, SWIMA-PCs MUST NOT attempt to combine information when fulfilling multiple subscriptions simultaneously, even if this results in some redundancy in the attributes sent to the SWIMA-PV.
SWIMA-PVは、特定のSWIMA-PCへの複数のサブスクリプションを確立する場合があります。この場合、エンドポイント上の単一の変更イベントが複数のサブスクリプションによるフルフィルメントを必要とする可能性があり、これらの各サブスクリプションを満たす属性に含まれる情報が重複する可能性があります。 SWIMA-PCは、所定のイベントによる応答を必要とする確立されたサブスクリプションごとに個別の属性を送信する必要があります。これらの各属性は、その情報が他のサブスクリプションのフルフィルメントで同時に送信される他の属性でも送信される場合でも、その個々のサブスクリプションをフルフィルメントするために必要なすべての情報を含む必要があります。言い換えると、SWIMA-PVに送信される属性に冗長性が生じたとしても、SWIMA-PCは複数のサブスクリプションを同時に満たすときに情報を結合しようとしてはなりません。
A SWIMA-PC MAY delay the fulfillment of a subscription following a change event in the interest of waiting to see if additional change events are forthcoming and, if so, conveying the relevant records back to the SWIMA-PV in a single SWIMA Response attribute. This can help reduce network bandwidth consumption between the SWIMA-PC and the SWIMA-PV. For example, consider a situation where 10 changes occur a tenth of a second apart. If the SWIMA-PC does not delay in assembling and sending SWIMA Response attributes, the SWIMA-PV will receive 10 separate SWIMA Response attributes over a period of 1 second. However, if the SWIMA-PC waits half a second after the initial event before assembling a SWIMA Response, the SWIMA-PV only receives two SWIMA Response attributes over the same period of time.
SWIMA-PCは、追加の変更イベントが発生するかどうかを確認するために待機し、該当する場合は関連するレコードを単一のSWIMA応答属性のSWIMA-PVに戻すために、変更イベントの後にサブスクリプションの実行を遅延させる場合があります。これにより、SWIMA-PCとSWIMA-PVの間のネットワーク帯域幅の消費を削減できます。たとえば、10の変更が1/10秒間隔で発生する状況を考えます。 SWIMA-PCがSWIMA応答属性の組み立てと送信を遅延しない場合、SWIMA-PVは1秒間に10個の個別のSWIMA応答属性を受信します。ただし、SWIMA-PCが最初のイベントから0.5秒待ってからSWIMA応答をアセンブルする場合、SWIMA-PVは同じ期間に2つのSWIMA応答属性のみを受信します。
Note that the ability to consolidate events for a single subscription over a given period of time does not contradict the rules in Section 3.8.5.4 prohibiting consolidation across multiple subscriptions. When delaying fulfillment of subscriptions, SWIMA-PCs are still required to fulfill each individual subscription separately. Moreover, in the case that change events within the delay window cancel each other out (e.g., a record is deleted and then re-added), the SWIMA-PC MUST still report each change event, rather than just report the net effect of changes over the delay period. In other words, delayed fulfillment can decrease the number of attributes sent by the SWIMA-PC, but it does not reduce the total number of change events reported.
特定の期間にわたって単一のサブスクリプションのイベントを統合する機能は、複数のサブスクリプション間での統合を禁止するセクション3.8.5.4のルールと矛盾しないことに注意してください。サブスクリプションの履行を遅らせる場合でも、SWIMA-PCは個々のサブスクリプションを個別に履行する必要があります。さらに、遅延ウィンドウ内の変更イベントが互いにキャンセルし合う場合（たとえば、レコードが削除されてから再度追加される場合）、SWIMA-PCは変更の正味の影響を報告するだけでなく、各変更イベントを報告する必要があります遅延期間中。つまり、フルフィルメントの遅延により、SWIMA-PCによって送信される属性の数は減少しますが、報告される変更イベントの総数は減少しません。
SWIMA-PCs are not required to support delayed fulfillment of subscriptions. However, in the case that the SWIMA-PC does support delayed subscription fulfillment, it MUST be possible to configure the SWIMA-PC to disable delayed fulfillment. In other words, parties deploying SWIMA-PCs need to be allowed to disable delayed subscription fulfillment in their SWIMA-PCs. The manner in which such configuration occurs is left to the discretion of implementers, although implementers MUST protect the configuration procedure from unauthorized tampering. In other words, there needs to be some assurance that unauthorized individuals are not able to introduce long delays in subscription fulfillment.
SWIMA-PCは、サブスクリプションのフルフィルメントの遅延をサポートする必要はありません。ただし、SWIMA-PCが遅延サブスクリプションのフルフィルメントをサポートしている場合は、遅延フルフィルメントを無効にするようにSWIMA-PCを構成できる必要があります。つまり、SWIMA-PCを展開する関係者は、SWIMA-PCでのサブスクリプションの遅延履行を無効にできるようにする必要があります。そのような構成が発生する方法は、実装者の裁量に任されていますが、実装者は、構成手順を不正な改ざんから保護しなければなりません（MUST）。言い換えれば、無許可の個人がサブスクリプションの履行に長い遅延を導入できないことをある程度保証する必要があります。
In the case where the SWIMA-PC detects an error in a SWIMA Request attribute that it receives, it MUST respond with a PA-TNC Error attribute with an error code appropriate to the nature of the error. (See Section 4.2.8 of PA-TNC [RFC5792] for more details about PA-TNC Error attributes and error codes, and see Section 5.15 in this specification for error codes specific to SWIMA attributes.) In the case that an error is detected in a SWIMA Request, the SWIMA-PC MUST NOT take any action requested by this SWIMA Request, even if partial completion of the request is possible. In other words, a SWIMA Request that contains an error will be completely ignored by the SWIMA-PC (beyond sending a PA-TNC Error attribute and possibly logging the error locally); no attempt at partial completion of the request will be made.
SWIMA-PCは、受信したSWIMA要求属性でエラーを検出した場合、エラーの性質に適したエラーコードを含むPA-TNCエラー属性で応答する必要があります。 （PA-TNCエラー属性とエラーコードの詳細については、PA-TNC [RFC5792]のセクション4.2.8を参照してください。SWIMA属性に固有のエラーコードについては、この仕様のセクション5.15を参照してください。）エラーが検出された場合SWIMA要求では、たとえ要求の部分的な完了が可能であっても、SWIMA-PCはこのSWIMA要求によって要求されたアクションを実行してはなりません（MUST NOT）。言い換えると、エラーを含むSWIMAリクエストはSWIMA-PCによって完全に無視されます（PA-TNCエラー属性を送信し、場合によってはエラーをローカルでログに記録する以外）。リクエストの部分的な完了は試みられません。
In the case where the SWIMA-PC receives a valid SWIMA Request attribute but experiences an error during the process of responding to that attribute's instructions where that error prevents the SWIMA-PC from properly or completely fulfilling that request, the SWIMA-PC MUST send a PA-TNC Error attribute with an error code appropriate to the nature of the error. In the case where a PA-TNC Error attribute is sent, the SWIMA-PC MUST NOT take any of the actions requested by the SWIMA Request attribute that led to the detected error. This is the case even if some actions could have been completed successfully and might even require the SWIMA-PC to reverse some successful actions already taken before the error condition was detected. In other words, either (1) all aspects of a SWIMA Request complete fully and successfully (in which case the SWIMA-PC sends a SWIMA Response attribute) or (2) no aspects of the SWIMA Request occur (in which case the SWIMA-PC sends a PA-TNC Error attribute). In the case that a SWIMA-PC sends a PA-TNC Error attribute in response to a SWIMA Request, then the SWIMA-PC MUST NOT also send any SWIMA Response attribute in response to the same SWIMA Request. For this reason, the sending of a SWIMA Response attribute MUST be the last action taken by a SWIMA-PC in response to a SWIMA Request, to avoid the possibility of a processing error occurring after that SWIMA Response attribute is sent.
SWIMA-PCが有効なSWIMA要求属性を受信したが、その属性の指示に応答するプロセス中にエラーが発生し、SWIMA-PCがその要求を適切にまたは完全に実行できなくなった場合、SWIMA-PCは、エラーの性質に適したエラーコードを持つPA-TNCエラー属性。 PA-TNCエラー属性が送信される場合、SWIMA-PCは、検出されたエラーの原因となったSWIMA要求属性によって要求されたアクションを実行してはなりません（MUST NOT）。これは、一部のアクションが正常に完了した可能性があり、SWIMA-PCがエラー状態が検出される前に既に実行された一部の成功したアクションを元に戻す必要がある場合でも当てはまります。つまり、（1）SWIMAリクエストのすべての側面が完全かつ正常に完了する（この場合、SWIMA-PCがSWIMA応答属性を送信する）か、または（2）SWIMAリクエストの側面が発生しない（この場合、SWIMA PCはPA-TNCエラー属性を送信します）。 SWIMA-PCがSWIMA要求に応答してPA-TNCエラー属性を送信する場合、SWIMA-PCは同じSWIMA要求に応答してSWIMA応答属性も送信してはならない（MUST NOT）。このため、SWIMA応答属性が送信された後に処理エラーが発生する可能性を回避するために、SWIMA応答属性の送信は、SWIMA要求に応答してSWIMA-PCが行う最後のアクションでなければなりません。
In the case that the SWIMA-PC detects an error that prevents it from properly or completely fulfilling its obligations under an active subscription, the SWIMA-PC MUST send a PA-TNC Error attribute with error code SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR to the SWIMA-PV that established this subscription. This type of PA-TNC Error attribute identifies the specific subscription that cannot be adequately honored due to the error condition and also identifies an error "subtype". The error subtype indicates the error code of the error condition the SWIMA-PC experienced that prevented it from honoring the given subscription. In the case that the error condition cannot be identified or does not align with any of the defined error codes, the SWIMA_ERROR error code SHOULD be used in the subtype. In the case that a SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR is sent, the associated subscription MUST be treated as cancelled by both the SWIMA-PC and the SWIMA-PV.
SWIMA-PCがアクティブサブスクリプションで義務を適切にまたは完全に満たすのを妨げるエラーを検出した場合、SWIMA-PCは、これを確立したSWIMA-PVにエラーコードSWIMA_SUBSCRIPTION_FULFILLMENT_ERRORを含むPA-TNCエラー属性を送信する必要があります。サブスクリプション。このタイプのPA-TNCエラー属性は、エラー条件が原因で十分に対応できない特定のサブスクリプションを識別し、エラー「サブタイプ」も識別します。エラーサブタイプは、SWIMA-PCで発生したエラー状態のエラーコードを示し、SWIMA-PCが指定されたサブスクリプションを受け入れることができませんでした。エラー条件を識別できない場合、または定義されたエラーコードのいずれとも一致しない場合、SWIMA_ERRORエラーコードをサブタイプで使用する必要があります（SHOULD）。 SWIMA_SUBSCRIPTION_FULFILLMENT_ERRORが送信された場合、関連付けられたサブスクリプションは、SWIMA-PCとSWIMA-PVの両方によってキャンセルされたものとして扱われる必要があります。
The SWIMA-PV MUST NOT send any PA-TNC Error attributes to SWIMA-PCs. In the case that a SWIMA-PV detects an error condition, it SHOULD log this error, but the SWIMA-PV does not inform any SWIMA-PCs of this event. Errors might include, but are not limited to, the detection of malformed SWIMA Response attributes sent from a given SWIMA-PC, as well as the detection of error conditions when the SWIMA-PV processes SWIMA Responses.
SWIMA-PVは、PA-TNCエラー属性をSWIMA-PCに送信してはなりません。 SWIMA-PVがエラー状態を検出した場合、このエラーをログに記録する必要があります（SHOULD）が、SWIMA-PVはこのイベントをSWIMA-PCに通知しません。エラーには、特定のSWIMA-PCから送信された不正なSWIMA応答属性の検出や、SWIMA-PVがSWIMA応答を処理するときのエラー状態の検出などが含まれます。
Both SWIMA-PCs and SWIMA-PVs SHOULD log errors so that administrators can trace the causes of errors. Log entries SHOULD include the code of the error, the time it was detected, and additional descriptive information to aid in understanding the nature and cause of the error. Logs are an important debugging tool, and implementers are strongly advised to include comprehensive logging capabilities in their products.
SWIMA-PCとSWIMA-PVの両方がエラーをログに記録して、管理者がエラーの原因を追跡できるようにする必要があります。ログエントリには、エラーのコード、エラーが検出された時間、およびエラーの性質と原因を理解するのに役立つ追加の説明情報を含める必要があります（SHOULD）。ログは重要なデバッグツールであり、実装者は製品に包括的なログ機能を含めることを強くお勧めします。
The SWIMA protocol supports two different types of message exchanges for conveying software inventory information. These message exchanges are described in the following subsections, along with implementation requirements for supporting them.
SWIMAプロトコルは、ソフトウェアインベントリ情報を伝達するための2種類のメッセージ交換をサポートしています。これらのメッセージ交換については、それらをサポートするための実装要件とともに、次のサブセクションで説明します。
The SWIMA protocol also supports two simple status exchanges: a Subscription Status exchange for conveying information about active subscriptions, and a Source Metadata exchange for conveying information about a SWIMA-PC's data sources. In both cases, a SWIMA-PV sends a request attribute (Subscription Status Request or Source Metadata Request, respectively) and a SWIMA-PC responds with a matching response attribute (Subscription Status Response or Source Metadata Response, respectively). As these exchanges are straightforward, no additional information on the exchanges is provided.
SWIMAプロトコルは、2つの単純なステータス交換もサポートしています。アクティブなサブスクリプションに関する情報を伝達するサブスクリプションステータス交換と、SWIMA-PCのデータソースに関する情報を伝達するソースメタデータ交換です。どちらの場合でも、SWIMA-PVは要求属性（それぞれサブスクリプションステータス要求またはソースメタデータ要求）を送信し、SWIMA-PCは一致する応答属性（それぞれサブスクリプションステータス応答またはソースメタデータ応答）で応答します。これらの交換は簡単なので、交換に関する追加情報は提供されません。
The first type of software information exchange is used to provide the SWIMA-PV with a software inventory or event collection from the queried endpoint.
最初のタイプのソフトウェア情報交換は、SWIMA-PVに、照会されたエンドポイントからのソフトウェアインベントリまたはイベントコレクションを提供するために使用されます。
+-------------+ +--------------+
| SWIMA-PC | | SWIMA-PV | Time
+-------------+ +--------------+ |
| | |
|<-----------SWIMA Request------------| |
| | |
| SWIMA Response* | |
|-----------------or----------------->| |
| PA-TNC Error | |
| | V
*SWIMA Response is one of the following: Software Identifier Inventory, Software Identifier Events, Software Inventory, or Software Events.
* SWIMA応答は、ソフトウェアIDインベントリ、ソフトウェアIDイベント、ソフトウェアインベントリ、またはソフトウェアイベントのいずれかです。
Figure 4: SWIMA Attribute Exchange (Direct Response to SWIMA Request)
図4：SWIMA属性交換（SWIMA要求への直接応答）
In this exchange, the SWIMA-PV indicates to the SWIMA-PC, via a SWIMA Request, the nature of the information it wishes to receive (inventory vs. events, full or targeted) and how it wishes the returned inventory to be expressed (with or without Software Inventory Evidence Records). The SWIMA-PC responds with the requested information using the appropriate attribute type. A single SWIMA Request MUST only lead to a single SWIMA Response or PA-TNC Error that is in direct response to that request.
この交換で、SWIMA-PVはSWIMAリクエストを介して、SWIMA-PCに、受信したい情報の性質（在庫とイベント、完全またはターゲット）、および返された在庫の表現方法（ソフトウェアインベントリエビデンスレコードの有無にかかわらず）。 SWIMA-PCは、適切な属性タイプを使用して、要求された情報で応答します。単一のSWIMA要求は、その要求に直接応答する単一のSWIMA応答またはPA-TNCエラーのみを引き起こす必要があります。
The second type of software information exchange allows change-event-based reporting based on a subscription. If there is an active subscription on the endpoint, the SWIMA-PC sends a SWIMA Response to the SWIMA-PV following a change event on the endpoint in fulfillment of that subscription. Such an exchange is shown in Figure 5.
2番目のタイプのソフトウェア情報交換では、サブスクリプションに基づく変更イベントベースのレポートが可能です。エンドポイントにアクティブなサブスクリプションがある場合、SWIMA-PCは、そのサブスクリプションの実行中にエンドポイントで変更イベントが発生した後、SWIMA応答をSWIMA-PVに送信します。そのような交換を図5に示します。
+-------------+ +--------------+
| SWIMA-PC | | SWIMA-PV | Time
+-------------+ +--------------+ |
| | |
<Change Event>| | |
|------SWIMA Response(s)*------>| |
| | |
| | V
*SWIMA Response is one of the following: Software Identifier Inventory, Software Identifier Events, Software Inventory, or Software Events.
* SWIMA応答は、ソフトウェアIDインベントリ、ソフトウェアIDイベント、ソフトウェアインベントリ、またはソフトウェアイベントのいずれかです。
Figure 5: SWIMA Attribute Exchange (in Fulfillment of an Active Subscription)
図5：SWIMA属性交換（アクティブなサブスクリプションのフルフィルメント）
Note that unlike direct responses to a SWIMA Request, a single change event can precipitate multiple SWIMA Responses for a single subscription, but only if all but the last of those SWIMA Responses convey partial lists of event records. When providing multiple SWIMA Responses in this way, the initial responses contain partial lists of event records and the last of those SWIMA Responses conveys the remainder of the relevant event records, completing the delivery of all relevant events in response to the change event. A single change event MUST NOT otherwise be followed by multiple SWIMA Responses or PA-TNC Error attributes in any combination.
SWIMA要求への直接応答とは異なり、1つの変更イベントが1つのサブスクリプションに対して複数のSWIMA応答を引き起こす可能性があることに注意してください。ただし、これらのSWIMA応答の最後以外のすべてがイベントレコードの部分リストを伝える場合に限ります。この方法で複数のSWIMA応答を提供する場合、最初の応答にはイベントレコードの部分的なリストが含まれ、それらの最後のSWIMA応答は残りの関連イベントレコードを伝え、変更イベントに応答してすべての関連イベントの配信を完了します。それ以外の場合、単一の変更イベントの後に、複数のSWIMA応答またはPA-TNCエラー属性を組み合わせて続けてはなりません（MUST NOT）。
All SWIMA-PVs and SWIMA-PCs MUST support both types of software information exchanges. In particular, SWIMA-PCs MUST be capable of pushing a SWIMA Response to a SWIMA-PV immediately upon detection of a change to the endpoint's Software Inventory Evidence Collection in fulfillment of established SWIMA-PV subscriptions, as described in Section 3.8.
すべてのSWIMA-PVおよびSWIMA-PCは、両方のタイプのソフトウェア情報交換をサポートする必要があります。特に、セクション3.8で説明されているように、SWIMA-PCは、確立されたSWIMA-PVサブスクリプションの履行におけるエンドポイントのソフトウェアインベントリエビデンスコレクションへの変更を検出するとすぐにSWIMA応答をSWIMA-PVにプッシュできる必要があります。
All SWIMA-PCs MUST support both status exchanges (Subscription Status and Source Metadata); SWIMA-PVs are recommended to support these status exchanges, but doing so is not required.
すべてのSWIMA-PCは両方のステータス交換（サブスクリプションステータスとソースメタデータ）をサポートする必要があります。これらのステータス交換をサポートするにはSWIMA-PVが推奨されますが、そうする必要はありません。
This section describes the format and semantics of the SWIMA protocol. This protocol uses the PA-TNC message header format [RFC5792].
このセクションでは、SWIMAプロトコルの形式とセマンティクスについて説明します。このプロトコルは、PA-TNCメッセージヘッダー形式[RFC5792]を使用します。
The NEA PB-TNC [RFC5793] interface provides a general message-batching protocol capable of carrying one or more PA-TNC messages between the Posture Broker Client and Posture Broker Server. When PB-TNC is carrying a PA-TNC message, the PB-TNC message headers contain a 32-bit identifier called the "PA Subtype". The PA Subtype field indicates the type of component associated with all of the PA-TNC attributes carried by the PB-TNC message. The core set of PA Subtypes is defined in the PA-TNC specification. This specification defines a new "SWIMA Attributes" PA Subtype, which is registered in Section 10.2 of this document and is used as a namespace for the collection of SWIMA attributes defined in this document.
NEA PB-TNC [RFC5793]インターフェイスは、Posture Broker ClientとPosture Broker Serverの間で1つ以上のPA-TNCメッセージを伝送できる一般的なメッセージバッチプロトコルを提供します。 PB-TNCがPA-TNCメッセージを伝送している場合、PB-TNCメッセージヘッダーには、「PAサブタイプ」と呼ばれる32ビットの識別子が含まれます。 PAサブタイプフィールドは、PB-TNCメッセージによって伝送されるすべてのPA-TNC属性に関連付けられたコンポーネントのタイプを示します。 PAサブタイプのコアセットは、PA-TNC仕様で定義されています。この仕様は、このドキュメントのセクション10.2に登録され、このドキュメントで定義されているSWIMA属性のコレクションの名前空間として使用される新しい「SWIMA属性」PAサブタイプを定義します。
For more information on PB-TNC messages and PA-TNC messages, as well as their message headers, see the PB-TNC [RFC5793] and PA-TNC [RFC5792] specifications, respectively.
PB-TNCメッセージとPA-TNCメッセージ、およびそれらのメッセージヘッダーの詳細については、それぞれPB-TNC [RFC5793]およびPA-TNC [RFC5792]仕様を参照してください。
Each PA-TNC attribute described in this specification is intended to be sent between the SWIMA-PC and SWIMA-PV and so will be carried in a PB-TNC message indicating a PA Subtype of "SWIMA Attributes". PB-TNC messages MUST always include the SWIMA Attributes Subtype defined in Section 5.1 when carrying SWIMA attributes over PA-TNC. The attributes defined in this specification appear below, along with a short summary of their purposes.
この仕様で説明されている各PA-TNC属性は、SWIMA-PCとSWIMA-PVの間で送信されることを目的としているため、「SWIMA属性」のPAサブタイプを示すPB-TNCメッセージで伝送されます。 PB-TNCメッセージには、PA-TNCを介してSWIMA属性を伝送するときに、セクション5.1で定義されたSWIMA属性サブタイプを必ず含める必要があります。この仕様で定義されている属性とその目的の簡単な要約を以下に示します。
PA-TNC attribute types are identified in the PA-TNC Attribute Header via the PA-TNC Attribute Vendor ID field and the PA-TNC Attribute Type field; see Section 4.1 of [RFC5792] for details. Table 1 identifies the appropriate values for these fields for each attribute type used within the SWIMA protocol. All attributes have a PEN value of 0x000000. Both the hexadecimal and decimal values are provided in the Integer column in the table. Each attribute is described in greater detail in subsequent sections (identified in the table's Description column).
PA-TNC属性タイプは、PA-TNC属性ベンダーIDフィールドとPA-TNC属性タイプフィールドを介してPA-TNC属性ヘッダーで識別されます。詳細については、[RFC5792]のセクション4.1をご覧ください。表1は、SWIMAプロトコル内で使用される各属性タイプのこれらのフィールドの適切な値を示しています。すべての属性のPEN値は0x000000です。 16進値と10進値の両方が、表の整数列に示されています。各属性については、以降のセクションでさらに詳しく説明します（表の[説明]列に示されています）。
+--------------+-----------------+----------------------------------+
| Attribute | Integer | Description |
| Name | | |
+--------------+-----------------+----------------------------------+
| SWIMA | 0x0000000D (13) | Request sent from a SWIMA-PV to |
| Request | | a SWIMA-PC for the SWIMA-PC to |
| | | provide a software inventory or |
| | | event list. It might also |
| | | establish a subscription. |
| | | (Section 5.6) |
| | | |
| Software | 0x0000000E (14) | An inventory sent without |
| Identifier | | Software Inventory Evidence |
| Inventory | | Records sent from a SWIMA-PC. |
| | | (Section 5.7) |
| | | |
| Software | 0x0000000F (15) | A collection of events impacting |
| Identifier | | the endpoint's Software |
| Events | | Inventory Evidence Collection, |
| | | where events do not include |
| | | Software Inventory Evidence |
| | | Records. (Section 5.8) |
| | | |
| Software | 0x00000010 (16) | An inventory including Software |
| Inventory | | Inventory Evidence Records sent |
| | | from a SWIMA-PC. (Section 5.9) |
| | | |
| Software | 0x00000011 (17) | A collection of events impacting |
| Events | | the endpoint's Software |
| | | Inventory Evidence Collection, |
| | | where events include Software |
| | | Inventory Evidence Records. |
| | | (Section 5.10) |
| | | |
| Subscription | 0x00000012 (18) | A request for a list of a |
| Status | | SWIMA-PV's active subscriptions |
| Request | | on a SWIMA-PC. (Section 5.11) |
| | | |
| Subscription | 0x00000013 (19) | A list of a SWIMA-PV's active |
| Status | | subscriptions on a SWIMA-PC. |
| Response | | (Section 5.12) |
| | | |
| Source | 0x00000014 (20) | A request for information about |
| Metadata | | a SWIMA-PC's data sources. |
| Request | | (Section 5.13) |
| | | |
| Source | 0x00000015 (21) | Descriptive metadata about a |
| Metadata | | SWIMA-PC's data sources. |
| Response | | (Section 5.14) |
| | | |
| PA-TNC Error | 0x00000008 (8) | An error attribute as defined in |
| | | the PA-TNC specification |
| | | [RFC5792]. |
+--------------+-----------------+----------------------------------+
Table 1: SWIMA Attribute Enumeration
表1：SWIMA属性の列挙
Because one of the Software Identifier Inventory, Software Identifier Events, Software Inventory, or Software Events attributes is expected to be sent to a SWIMA-PV in direct response to a SWIMA Request attribute or in fulfillment of an active subscription, those four attribute types are referred to collectively in this document as "SWIMA Response attributes".
ソフトウェアIDインベントリ、ソフトウェアIDイベント、ソフトウェアインベントリ、またはソフトウェアイベント属性の1つは、SWIMAリクエスト属性への直接の応答で、またはアクティブなサブスクリプションの履行でSWIMA-PVに送信されると予想されるため、これらの4つの属性タイプはこのドキュメントでは、「SWIMA応答属性」と総称されます。
All SWIMA-PVs MUST be capable of sending SWIMA Request attributes and be capable of receiving and processing all SWIMA Response attributes as well as PA-TNC Error attributes. All SWIMA-PCs MUST be capable of receiving and processing SWIMA Request attributes and be capable of sending all types of SWIMA Response attributes as well as PA-TNC Error attributes. SWIMA-PVs MUST ignore any SWIMA Request attributes that they receive. SWIMA-PCs MUST ignore any SWIMA Response attributes or PA-TNC Error attributes that they receive.
すべてのSWIMA-PVは、SWIMA要求属性を送信でき、すべてのSWIMA応答属性とPA-TNCエラー属性を受信して処理できる必要があります。すべてのSWIMA-PCは、SWIMA要求属性を受信および処理でき、すべてのタイプのSWIMA応答属性およびPA-TNCエラー属性を送信できる必要があります。 SWIMA-PVは、受信するSWIMA要求属性を無視する必要があります。 SWIMA-PCは、受信するSWIMA応答属性またはPA-TNCエラー属性を無視する必要があります。
This specification uses diagrams to define the syntax of new PA-TNC messages and attributes. Each diagram depicts the format and size of each field in bits. Implementations MUST send the bits depicted in each diagram as they are shown from left to right for each 32-bit quantity, "traversing" the diagram from top to bottom. Fields representing numeric values MUST be sent in network (big endian) byte order.
この仕様では、ダイアグラムを使用して、新しいPA-TNCメッセージと属性の構文を定義します。各図は、各フィールドのフォーマットとサイズをビット単位で示しています。実装は、図を上から下に「トラバース」する32ビットの量ごとに左から右に示されているように、各図に示されたビットを送信する必要があります。数値を表すフィールドは、ネットワーク（ビッグエンディアン）バイトオーダーで送信する必要があります。
Descriptions of bit field (e.g., flag) values refer to the position of the bit within the field. These bit positions are numbered from the most significant bit through the least significant bit. As such, an octet with only bit 0 set would have a value of 0x80 (1000 0000), an octet with only bit 1 set would have a value of 0x40 (0100 0000), and an octet with only bit 7 set would have a value of 0x01 (0000 0001).
ビットフィールド（フラグなど）の値の説明は、フィールド内のビットの位置を参照します。これらのビット位置は、最上位ビットから最下位ビットまで番号が付けられています。したがって、ビット0のみが設定されたオクテットの値は0x80（1000 0000）、ビット1のみが設定されたオクテットの値は0x40（0100 0000）、ビット7のみが設定されたオクテットは値は0x01（0000 0001）。
In order to ensure consistency of transmitted attributes, some fields require normalization of their format. When this is necessary, this information is indicated in the field's description. In such cases, the field contents MUST be normalized to Network Unicode format as defined in RFC 5198 [RFC5198]. Network Unicode format defines a refinement of UTF-8 [RFC3629] that ensures a normalized expression of characters. SWIMA-PCs and SWIMA-PVs MUST NOT perform conversion and normalization on any field values except those specifically identified in the following sections as requiring normalization. Note, however, that some data models require additional normalization before source information is added to an endpoint's Software Inventory Evidence Collection as a record. The references from the "Software Data Model Types" registry (see Section 10.5) will note where this is necessary.
送信された属性の一貫性を確保するために、一部のフィールドでは形式の正規化が必要です。これが必要な場合、この情報はフィールドの説明に示されます。このような場合、RFC 5198 [RFC5198]で定義されているように、フィールドの内容をネットワークUnicode形式に正規化する必要があります。ネットワークUnicode形式は、文字の正規化された表現を保証するUTF-8 [RFC3629]の改良を定義しています。 SWIMA-PCとSWIMA-PVは、次のセクションで正規化が必要と特定されているフィールド値を除き、フィールド値の変換と正規化を実行してはなりません（MUST NOT）。ただし、一部のデータモデルでは、ソース情報をエンドポイントのソフトウェアインベントリエビデンスコレクションにレコードとして追加する前に、追加の正規化が必要です。 「ソフトウェアデータモデルタイプ」レジストリ（セクション10.5を参照）からの参照は、これが必要な場所を示します。
All SWIMA Request attributes MUST include a Request ID value. The Request ID field provides a value that identifies a given request relative to other requests between a SWIMA-PV and the receiving SWIMA-PC. Specifically, the SWIMA-PV assigns each SWIMA Request attribute a Request ID value that is intended to be unique within the lifetime of a given network Connection ID.
すべてのSWIMA要求属性には、要求ID値を含める必要があります。要求IDフィールドは、SWIMA-PVと受信SWIMA-PCの間の他の要求と比較して、特定の要求を識別する値を提供します。具体的には、SWIMA-PVは各SWIMA要求属性に、特定のネットワーク接続IDの存続期間内で一意になるように意図された要求ID値を割り当てます。
In the case that a SWIMA Request requests the establishment of a subscription and the receiving SWIMA-PC agrees to that subscription, the Request ID of that SWIMA Request (i.e., the establishing request of the subscription) becomes that subscription's Subscription ID. All attributes sent in fulfillment of this subscription include a flag indicating that the attribute fulfills a subscription and the subscription's Subscription ID. A SWIMA-PV MUST NOT reuse a Request ID value in communications with a given SWIMA-PC while that Request ID is also serving as a Subscription ID for an active subscription with that SWIMA-PC. In the case where a SWIMA-PC receives a SWIMA Request from a given SWIMA-PV where that Request ID is also the Subscription ID of an active subscription with that SWIMA-PV, the SWIMA-PC MUST respond with a PA-TNC Error attribute with an error code of SWIMA_SUBSCRIPTION_ID_REUSE_ERROR. Note that this error does not cancel the indicated subscription.
SWIMA要求がサブスクリプションの確立を要求し、受信側のSWIMA-PCがそのサブスクリプションに同意する場合、そのSWIMA要求の要求ID（つまり、サブスクリプションの確立要求）がそのサブスクリプションのサブスクリプションIDになります。このサブスクリプションのフルフィルメントで送信されるすべての属性には、属性がサブスクリプションとサブスクリプションのサブスクリプションIDを満たしていることを示すフラグが含まれています。 SWIMA-PVは、指定されたSWIMA-PCとの通信で要求ID値を再利用してはなりません（MUST）。その要求IDは、そのSWIMA-PCのアクティブなサブスクリプションのサブスクリプションIDとしても機能します。 SWIMA-PCが特定のSWIMA-PVからSWIMAリクエストを受信した場合、そのリクエストIDはそのSWIMA-PVを持つアクティブなサブスクリプションのサブスクリプションIDでもあり、SWIMA-PCはPA-TNCエラー属性で応答する必要があります。エラーコードはSWIMA_SUBSCRIPTION_ID_REUSE_ERRORです。このエラーは、示されたサブスクリプションをキャンセルしないことに注意してください。
Subscription Status Requests and Subscription Status Responses do not include Request IDs.
サブスクリプションステータスリクエストとサブスクリプションステータスレスポンスには、リクエストIDは含まれません。
In the case where all possible Request ID values have been exhausted within the lifetime of a single network Connection ID, the sender MAY reuse previously used Request IDs within the same network connection if the ID is not being used as a Subscription ID. In the case where reuse is necessary due to exhaustion of possible ID values, the SWIMA-PV SHOULD structure the reuse to maximize the time between original and subsequent use. The Request ID value is included in a SWIMA Response attribute directly responding to this SWIMA Request to indicate which SWIMA Request was received and caused the response. Request IDs can be randomly generated or sequential, as long as values are not repeated per the rules in this paragraph. SWIMA-PCs are not required to check for duplicate Request IDs, except insofar as is necessary to detect Subscription ID reuse.
単一のネットワーク接続IDの有効期間内にすべての可能なリクエストID値が使い果たされた場合、IDがサブスクリプションIDとして使用されていない場合、送信者は同じネットワーク接続内で以前に使用されたリクエストIDを再利用できます。可能なID値の枯渇により再利用が必要な場合、SWIMA-PVは、再利用を構造化して、最初の使用とその後の使用の間の時間を最大化する必要があります（SHOULD）。要求ID値は、このSWIMA要求に直接応答するSWIMA応答属性に含まれ、どのSWIMA要求が受信されて応答が発生したかを示します。この段落のルールに従って値が繰り返されない限り、リクエストIDはランダムに生成することも、シーケンシャルに生成することもできます。 SWIMA-PCは、サブスクリプションIDの再利用を検出する必要がある場合を除いて、重複するリクエストIDをチェックする必要はありません。
A SWIMA-PV sends this attribute to a SWIMA-PC to request that the SWIMA-PC send software inventory information to the SWIMA-PV. A SWIMA-PC MUST NOT send this attribute.
SWIMA-PVはこの属性をSWIMA-PCに送信して、SWIMA-PCがソフトウェアインベントリ情報をSWIMA-PVに送信するよう要求します。 SWIMA-PCはこの属性を送信してはなりません。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Software Identifier Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Earliest EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SUB-BLOCK (Repeated "Software Identifier Count" times) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: SWIMA Request Attribute
図6：SWIMAリクエスト属性
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Identifier Length | Software Identifier (var len) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: SWIMA Request Attribute SUB-BLOCK
図7：SWIMAリクエスト属性のサブブロック
+---------------+---------------------------------------------------+
| Field | Description |
+---------------+---------------------------------------------------+
| Flags: Bit 0 | If set (1), the SWIMA-PC MUST delete all |
| - Clear | subscriptions established by the requesting |
| Subscriptions | SWIMA-PV (barring any errors). |
| | |
| Flags: Bit 1 | If set (1), in addition to responding to the |
| - Subscribe | request as described, the SWIMA-PC MUST establish |
| | a subscription with parameters matching those in |
| | the SWIMA Request attribute (barring any errors). |
| | |
| Flags: Bit 2 | If unset (0), the SWIMA-PC's response MUST |
| - Result Type | include Software Inventory Evidence Records, and |
| | thus the response MUST be a Software Inventory, |
| | Software Events, or PA-TNC Error attribute. If |
| | set (1), the response MUST NOT include Software |
| | Inventory Evidence Records, and thus the response |
| | MUST be a Software Identifier Inventory, Software |
| | Identifier Events, or PA-TNC Error attribute. |
| | |
| Flags: Bits | Reserved for future use. This field MUST be set |
| 3-7 - | to zero on transmission and ignored upon |
| Reserved | reception. |
| | |
| Software | A 3-byte unsigned integer indicating the number |
| Identifier | of Software Identifiers that follow. If this |
| Count | value is non-zero, this is a targeted request, as |
| | described in Section 3.5. The Software |
| | Identifier Length and Software Identifier fields |
| | are repeated, in order, the number of times |
| | indicated in this field. In the case where |
| | Software Identifiers are present, the SWIMA-PC |
| | MUST only report software that corresponds to the |
| | identifiers the SWIMA-PV provided in this |
| | attribute (or respond with a PA-TNC Error |
| | attribute). This field value MAY be 0, in which |
| | case there are no instances of the Software |
| | Identifier Length and Software Identifier fields. |
| | In this case, the SWIMA-PV is indicating an |
| | interest in all Software Inventory Evidence |
| | Records on the endpoint (i.e., this is not a |
| | targeted request). |
| | |
| Request ID | A value that uniquely identifies this SWIMA |
| | Request from a particular SWIMA-PV. |
| | |
| Earliest EID | In the case where the SWIMA-PV is requesting |
| | software events, this field contains the EID |
| | value of the earliest event the SWIMA-PV wishes |
| | to have reported. (Note: The report will be |
| | inclusive of the event with this EID value.) In |
| | the case where the SWIMA-PV is requesting an |
| | inventory, then this field MUST be 0 |
| | (0x00000000). In the case where this field is |
| | non-zero, the SWIMA-PV is requesting events, and |
| | the SWIMA-PC MUST respond using a Software |
| | Events, Software Identifier Events, or PA-TNC |
| | Error attribute. In the case where this field is |
| | zero, the SWIMA-PV is requesting an inventory, |
| | and the SWIMA-PC MUST respond using a Software |
| | Inventory, Software Identifier Inventory, or |
| | PA-TNC Error attribute. |
| | |
| Software | A 2-byte unsigned integer indicating the length, |
| Identifier | in bytes, of the Software Identifier field. |
| Length | |
| | |
| Software | A string containing the Software Identifier value |
| Identifier | from a Software Inventory Evidence Record. This |
| | field value MUST be normalized to Network Unicode |
| | format, as described in Section 5.4. This string |
| | MUST NOT be null terminated. |
+---------------+---------------------------------------------------+
Table 2: SWIMA Request Attribute Fields
表2：SWIMA要求属性フィールド
The SWIMA-PV sends the SWIMA Request attribute to a SWIMA-PC to request the indicated information. Note that between the Result Type flag and the Earliest EID field, the SWIMA-PC is constrained to a single possible SWIMA Response attribute type (or a PA-TNC Error attribute) in its response to the request.
SWIMA-PVはSWIMA要求属性をSWIMA-PCに送信して、指定された情報を要求します。結果タイプフラグと最古のEIDフィールドの間では、SWIMA-PCは、要求への応答において、単一の可能なSWIMA応答属性タイプ（またはPA-TNCエラー属性）に制限されていることに注意してください。
The Subscribe flag and the Clear Subscriptions flag are used to manage subscriptions for the requesting SWIMA-PV on the receiving SWIMA-PC. Specifically, an attribute with the Subscribe flag set seeks to establish a new subscription by the requesting SWIMA-PV to the given SWIMA-PC, while an attribute with the Clear Subscriptions flag set seeks to delete all existing subscriptions by the requesting SWIMA-PV on the given SWIMA-PC. Note that in the latter case, only the subscriptions associated with the Connection ID and the Posture Validator Identifier of the requester are deleted as described in Section 3.8.3. A newly established subscription has the parameters outlined in the SWIMA Request attribute. Specifically, the Result Type flag indicates the type of result to send in fulfillment of the subscription, the value of the Earliest EID field indicates whether the fulfillment attributes list inventories or events, and the fields describing Software Identifiers (if present) indicate if and how a subscription is targeted. In the case that the SWIMA-PC is unable or unwilling to comply with the SWIMA-PV's request to establish or clear subscriptions, the SWIMA-PC MUST respond with a PA-TNC Error attribute with the SWIMA_SUBSCRIPTION_DENIED_ERROR error code. If the SWIMA-PV requests that subscriptions be cleared but has no existing subscriptions, this is not an error.
サブスクライブフラグとクリアサブスクリプションフラグは、受信側のSWIMA-PCで要求しているSWIMA-PVのサブスクリプションを管理するために使用されます。具体的には、Subscribeフラグが設定された属性は、要求されたSWIMA-PVによって指定されたSWIMA-PCに新しいサブスクリプションを確立しようとしますが、Clear Subscriptionsフラグが設定された属性は、要求したSWIMA-PVによって既存のサブスクリプションをすべて削除しようとします。指定されたSWIMA-PC。後者の場合、セクション3.8.3で説明されているように、リクエスタの接続IDとポスチャバリデータ識別子に関連付けられているサブスクリプションのみが削除されることに注意してください。新しく確立されたサブスクリプションには、SWIMA要求属性で概説されているパラメーターがあります。具体的には、結果タイプフラグは、サブスクリプションのフルフィルメントで送信する結果のタイプを示し、Earliest EIDフィールドの値は、フルフィルメント属性がインベントリまたはイベントをリストするかどうかを示し、ソフトウェア識別子（存在する場合）を説明するフィールドは、その方法と方法を示しますサブスクリプションが対象です。 SWIMA-PCが、サブスクリプションを確立またはクリアするというSWIMA-PVの要求に準拠できない、または準拠しない場合、SWIMA-PCは、SWIMA_SUBSCRIPTION_DENIED_ERRORエラーコードを含むPA-TNCエラー属性で応答する必要があります。 SWIMA-PVがサブスクリプションのクリアを要求したが、既存のサブスクリプションがない場合、これはエラーではありません。
An attribute requesting the establishment of a subscription is effectively doing "double duty", as it is a request for an immediate response from the SWIMA-PC in addition to setting up the subscription. Assuming that the SWIMA-PC is willing to comply with the subscription, it MUST send an appropriate response attribute to a request with the Subscribe flag set containing all requested information. The same is true of the Clear Subscriptions flag -- assuming that there is no error, the SWIMA-PC MUST generate a response attribute without regard to the presence of this flag, in addition to clearing its subscription list.
サブスクリプションの確立を要求する属性は、サブスクリプションのセットアップに加えてSWIMA-PCからの即時応答の要求であるため、実質的に「二重の義務」を果たしています。 SWIMA-PCがサブスクリプションに応じる用意があると仮定すると、SWIMA-PCは、要求されたすべての情報を含むサブスクライブフラグが設定された要求に適切な応答属性を送信する必要があります。同じことがClear Subscriptionsフラグにも当てはまります。エラーがないと仮定すると、SWIMA-PCは、サブスクリプションリストをクリアすることに加えて、このフラグの存在に関係なく応答属性を生成する必要があります。
Both the Subscribe flag and the Clear Subscriptions flag MAY be set in a single SWIMA Request attribute. In the case where this request is successful, the end result MUST be equivalent to the SWIMA-PC clearing its subscription list for the given SWIMA-PV first and then creating a new subscription in accordance with the request parameters. In other words, do not first create the new subscription and then clear all the subscriptions (including the one that was just created). In the case that the requested actions are successfully completed, the SWIMA-PC MUST respond with a SWIMA Response attribute. The specific type of SWIMA Response attribute depends on the Result Type flag and the Earliest EID field, as described above. In the case where there is a failure that prevents some part of this request from completing, the SWIMA-PC MUST NOT add a new subscription, MUST NOT clear the old subscriptions, and MUST respond with a PA-TNC Error attribute. In other words, the SWIMA-PC MUST NOT partially succeed at implementing such a request; either all actions succeed or none succeed.
サブスクライブフラグとクリアサブスクリプションフラグの両方を単一のSWIMAリクエスト属性で設定できます。このリクエストが成功した場合、最終結果は、SWIMA-PCが指定されたSWIMA-PVのサブスクリプションリストを最初にクリアしてから、リクエストパラメータに従って新しいサブスクリプションを作成することと同等でなければなりません。つまり、最初に新しいサブスクリプションを作成してから、すべてのサブスクリプション（作成したばかりのサブスクリプションを含む）をクリアしないでください。要求されたアクションが正常に完了した場合、SWIMA-PCはSWIMA応答属性で応答する必要があります。 SWIMA応答属性の特定のタイプは、上記のように、結果タイプフラグと最古のEIDフィールドによって異なります。この要求の一部の完了を妨げる障害が発生した場合、SWIMA-PCは新しいサブスクリプションを追加してはならず（MUST NOT）、古いサブスクリプションをクリアしてはならず（MUST NOT）、PA-TNCエラー属性で応答しなければなりません（MUST）。言い換えれば、SWIMA-PCはそのようなリクエストの実装に部分的に成功してはならない（MUST NOT）。すべてのアクションが成功するか、何も成功しません。
The Earliest EID field is used to indicate if the SWIMA-PV is requesting an inventory or event list from the SWIMA-PC. A value of 0 (0x00000000) represents a request for inventory information. Otherwise, the SWIMA-PV is requesting event information. For Earliest EID values other than 0, the SWIMA-PC MUST respond with event records, as described in Section 3.7. Note that the request does not identify a particular EID Epoch, since responses can only include events in the SWIMA-PC's current EID Epoch.
Earliest EIDフィールドは、SWIMA-PVがSWIMA-PCにインベントリまたはイベントリストを要求しているかどうかを示すために使用されます。値0（0x00000000）は、インベントリ情報の要求を表します。それ以外の場合、SWIMA-PVはイベント情報を要求しています。セクション3.7で説明されているように、0以外の最も早いEID値の場合、SWIMA-PCはイベントレコードで応答する必要があります。応答にはSWIMA-PCの現在のEIDエポックのイベントのみを含めることができるため、リクエストは特定のEIDエポックを識別しないことに注意してください。
The Software Identifier Count indicates the number of Software Identifiers in the attribute. This number might be any value between 0 and 16,777,216, inclusive. A single Software Identifier is represented by the following fields: Software Identifier Length and Software Identifier. These fields are repeated a number of times equal to the Software Identifier Count, which may be 0. The Software Identifier Length field indicates the number of bytes allocated to the Software Identifier field. The Software Identifier field contains a Software Identifier as described in Section 3.4.1. The presence of one or more Software Identifiers is used by the SWIMA-PV to indicate a targeted request, which seeks only inventories of or events affecting software corresponding to the given identifiers. The SWIMA-PC MUST only report software that matched the Software Identifiers provided in the SWIMA-PV's SWIMA Request attribute.
ソフトウェアIDカウントは、属性内のソフトウェアIDの数を示します。この数値は、0から16,777,216までの任意の値にすることができます。単一のソフトウェア識別子は、次のフィールドで表されます：ソフトウェア識別子の長さおよびソフトウェア識別子。これらのフィールドは、ソフトウェア識別子カウント（0の場合もある）と同じ回数だけ繰り返されます。ソフトウェア識別子の長さフィールドは、ソフトウェア識別子フィールドに割り当てられたバイト数を示します。ソフトウェア識別子フィールドには、セクション3.4.1で説明されているソフトウェア識別子が含まれています。 SWIMA-PVは1つ以上のソフトウェア識別子の存在を使用して、指定された識別子に対応するソフトウェアに影響を与えるソフトウェアのインベントリまたはイベントのみを探す対象の要求を示します。 SWIMA-PCは、SWIMA-PVのSWIMA要求属性で提供されるソフトウェア識別子と一致するソフトウェアのみを報告する必要があります。
A SWIMA-PC sends this attribute to a SWIMA-PV to convey the inventory of the endpoint's Software Inventory Evidence Collection without the inclusion of Software Inventory Evidence Records. This list might represent a complete inventory or a targeted list of records, depending on the parameters in the SWIMA-PV's request. A SWIMA-PV MUST NOT send this attribute. The SWIMA-PC sends this attribute either (1) in fulfillment of an existing subscription where the establishing request has a Result Type of 1 and the Earliest EID is zero or (2) in direct response to a SWIMA Request attribute where the Result Type is 1 and the Earliest EID is zero.
SWIMA-PCはこの属性をSWIMA-PVに送信して、ソフトウェアインベントリエビデンスレコードを含めることなく、エンドポイントのソフトウェアインベントリエビデンスコレクションのインベントリを伝えます。このリストは、SWIMA-PVのリクエストのパラメータに応じて、完全なインベントリまたはターゲットレコードのリストを表す場合があります。 SWIMA-PVはこの属性を送信してはなりません。 SWIMA-PCは、（1）確立要求の結果タイプが1で、Earliest EIDがゼロである既存のサブスクリプションの履行で、または（2）結果タイプがSWIMA要求属性に直接応答して、この属性を送信します。 1で、Earliest EIDはゼロです。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Software Identifier Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID Copy / Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EID Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SUB-BLOCK (Repeated "Software Identifier Count" times) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Software Identifier Inventory Attribute
図8：ソフトウェア識別子のインベントリ属性
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Model Type PEN |Data Model Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Id Num | Reserved | Software Identifier Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Locator Length |Software Locator (variable len)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Software Identifier Inventory Attribute SUB-BLOCK
図9：ソフトウェア識別子のインベントリ属性のサブブロック
+----------------+--------------------------------------------------+
| Field | Description |
+----------------+--------------------------------------------------+
| Flags: Bit 0 - | In the case that this attribute is sent in |
| Subscription | fulfillment of a subscription, this bit MUST be |
| Fulfillment | set (1). In the case that this attribute is a |
| | direct response to a SWIMA Request, this bit |
| | MUST be unset (0). |
| | |
| Flags: Bits | Reserved for future use. This field MUST be set |
| 1-7 - Reserved | to zero on transmission and ignored upon |
| | reception. |
| | |
| Software | The number of Software Identifiers that follow. |
| Identifier | This field is an unsigned integer. The Record |
| Count | Identifier, Data Model Type PEN, Data Model |
| | Type, Source Identification Number, Reserved, |
| | Software Identifier Length, Software Identifier, |
| | Software Locator Length, and Software Locator |
| | fields are repeated, in order, the number of |
| | times indicated in this field. This field value |
| | MAY be 0, in which case there are no instances |
| | of these fields. |
| | |
| Request ID | In the case where this attribute is in direct |
| Copy / | response to a SWIMA Request attribute from a |
| Subscription | SWIMA-PV, this field MUST contain an exact copy |
| ID | of the Request ID field from that SWIMA Request. |
| | In the case where this attribute is sent in |
| | fulfillment of an active subscription, this |
| | field MUST contain the Subscription ID of the |
| | subscription being fulfilled by this attribute. |
| | |
| EID Epoch | The EID Epoch of the Last EID value. This field |
| | is a 4-byte unsigned integer. |
| | |
| Last EID | The EID of the last event recorded by the |
| | SWIMA-PC, or 0 if the SWIMA-PC has no recorded |
| | events. This field is a 4-byte unsigned |
| | integer. |
| | |
| Record | A 4-byte unsigned integer containing the Record |
| Identifier | Identifier value from a Software Inventory |
| | Evidence Record. |
| | |
| Data Model | A 3-byte unsigned integer containing the Private |
| Type PEN | Enterprise Number (PEN) of the organization that |
| | assigned the meaning of the Data Model Type |
| | value. |
| | |
| Data Model | A 1-byte unsigned integer containing an |
| Type | identifier number that identifies the data model |
| | of the reported record. |
| | |
| Source | The Source Identifier number associated with the |
| Identification | source from which this software installation |
| Number | inventory instance was reported. |
| | |
| Reserved | Reserved for future use. This field MUST be set |
| | to zero on transmission and ignored upon |
| | reception. |
| | |
| Software | A 2-byte unsigned integer indicating the length, |
| Identifier | in bytes, of the Software Identifier field. |
| Length | |
| | |
| Software | A string containing the Software Identifier |
| Identifier | value from a Software Inventory Evidence Record. |
| | This field value MUST be normalized to Network |
| | Unicode format, as described in Section 5.4. |
| | This string MUST NOT be null terminated. |
| | |
| Software | A 2-byte unsigned integer indicating the length, |
| Locator Length | in bytes, of the Software Locator field. |
| | |
| Software | A string containing the Software Locator value. |
| Locator | This field value MUST first be normalized to |
| | Network Unicode format, as described in |
| | Section 5.4, and then encoded as a URI |
| | [RFC3986]. This string MUST NOT be null |
| | terminated. |
+----------------+--------------------------------------------------+
Table 3: Software Identifier Inventory Attribute Fields
表3：ソフトウェア識別子のインベントリ属性フィールド
In the case that this attribute is sent in fulfillment of a subscription, the Subscription Fulfillment bit MUST be set (1). In the case that this attribute is sent in direct response to a SWIMA Request, the Subscription Fulfillment bit MUST be unset (0). Note that the SWIMA Response attribute sent in direct response to a SWIMA Request that establishes a subscription (i.e., a subscription's establishing request) MUST be treated as a direct response to that SWIMA Request (and thus the Subscription Fulfillment bit is unset). SWIMA Response attributes are only treated as being in fulfillment of a subscription (i.e., Subscription Fulfillment bit set) if they are sent following a change event, as shown in Figure 3.
この属性がサブスクリプションのフルフィルメントで送信される場合、サブスクリプションフルフィルメントビットを設定する必要があります（1）。この属性がSWIMA要求への直接の応答で送信される場合、サブスクリプションフルフィルメントビットの設定を解除する必要があります（0）。サブスクリプションを確立するSWIMA要求（つまり、サブスクリプションの確立要求）への直接応答で送信されるSWIMA応答属性は、そのSWIMA要求への直接応答として扱われる必要があることに注意してください（したがって、サブスクリプションフルビットは設定されていません）。 SWIMA応答属性は、図3に示すように、変更イベントの後に送信された場合にのみ、サブスクリプション（サブスクリプションフルフィルメントビットセット）を満たしているものとして扱われます。
The Software Identifier Count field indicates the number of Software Identifiers present in this inventory. Each Software Identifier is represented by the following set of fields: Record Identifier, Data Model Type PEN, Data Model Type, Source Identification Number, Reserved, Software Identifier Length, Software Identifier, Software Locator Length, and Software Locator. These fields will appear once for each reported record.
「ソフトウェアIDカウント」フィールドは、このインベントリーに存在するソフトウェアIDの数を示します。各ソフトウェア識別子は、レコード識別子、データモデルタイプPEN、データモデルタイプ、ソース識別番号、予約済み、ソフトウェア識別子の長さ、ソフトウェア識別子、ソフトウェアロケーター長、およびソフトウェアロケーターのフィールドセットで表されます。これらのフィールドは、報告されたレコードごとに1回表示されます。
When responding directly to a SWIMA Request attribute, the Request ID Copy / Subscription ID field MUST contain an exact copy of the Request ID field from that SWIMA Request. When this attribute is sent in fulfillment of an existing subscription on this SWIMA-PC, this field MUST contain the Subscription ID of the fulfilled subscription.
SWIMAリクエスト属性に直接応答する場合、リクエストIDコピー/サブスクリプションIDフィールドには、そのSWIMAリクエストからのリクエストIDフィールドの正確なコピーを含める必要があります。このSWIMA-PCの既存のサブスクリプションのフルフィルメントでこの属性が送信される場合、このフィールドには、フルフィルメントされたサブスクリプションのサブスクリプションIDが含まれている必要があります。
The EID Epoch field indicates the EID Epoch of the Last EID value. The Last EID field MUST contain the EID of the last recorded change event (see Section 3.7 for more about EIDs and recorded events) at the time this inventory was collected. In the case where there are no recorded change events at the time that this inventory was collected, the Last EID field MUST contain 0. These fields can be interpreted to indicate that the provided inventory reflects the state of the endpoint after all changes up to and including this last event have been accounted for.
EIDエポックフィールドは、最後のEID値のEIDエポックを示します。 Last EIDフィールドには、このインベントリが収集された時点で最後に記録された変更イベントのEID（EIDおよび記録されたイベントの詳細についてはセクション3.7を参照）が含まれている必要があります。このインベントリが収集されたときに記録された変更イベントがない場合、Last EIDフィールドには0が含まれている必要があります。これらのフィールドは、提供されたインベントリがまでのすべての変更後のエンドポイントの状態を反映していることを示すと解釈できます。この最後のイベントを含めて説明されています。
The Data Model Type PEN and Data Model Type fields are used to identify the data model associated with the given software record. These fields are discussed more in Section 3.4.2.
データモデルタイプPENおよびデータモデルタイプフィールドは、特定のソフトウェアレコードに関連付けられたデータモデルを識別するために使用されます。これらのフィールドについては、セクション3.4.2で詳しく説明します。
The Source Identification Number field is used to identify the source that provided the given record, as described in Section 3.1.
ソース識別番号フィールドは、セクション3.1で説明されているように、特定のレコードを提供したソースを識別するために使用されます。
A SWIMA-PC sends this attribute to a SWIMA-PV to convey events where the affected records are reported without Software Inventory Evidence Records. A SWIMA-PV MUST NOT send this attribute. The SWIMA-PC sends this attribute either (1) in fulfillment of an existing subscription where the establishing request has a Result Type of 1 and the Earliest EID is non-zero or (2) in direct response to a SWIMA Request attribute where the Result Type is 1 and the Earliest EID is non-zero.
SWIMA-PCはこの属性をSWIMA-PVに送信し、影響を受けるレコードがソフトウェアインベントリエビデンスレコードなしで報告されるイベントを伝えます。 SWIMA-PVはこの属性を送信してはなりません。 SWIMA-PCがこの属性を送信するのは、（1）確立要求の結果タイプが1で、Earliest EIDがゼロ以外の既存のサブスクリプションが満たされている場合、または（2）結果がSWIMA要求属性に直接応答した場合です。タイプは1で、Earliest EIDはゼロ以外です。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Event Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID Copy / Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EID Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Consulted EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SUB-BLOCK (Repeated "Event Count" times) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Software Identifier Events Attribute
図10：ソフトウェア識別子イベント属性
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- -+
| Timestamp |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Model Type PEN |Data Model Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Id Num | Action | Software Identifier Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Locator Length |Software Locator (variable len)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Software Identifier Events Attribute SUB-BLOCK
図11：ソフトウェア識別子イベント属性SUB-BLOCK
+----------------+--------------------------------------------------+
| Field | Description |
+----------------+--------------------------------------------------+
| Flags: Bit 0 - | In the case that this attribute is sent in |
| Subscription | fulfillment of a subscription, this bit MUST be |
| Fulfillment | set (1). In the case that this attribute is a |
| | direct response to a SWIMA Request, this bit |
| | MUST be unset (0). |
| | |
| Flags: Bits | Reserved for future use. This field MUST be set |
| 1-7 - Reserved | to zero on transmission and ignored upon |
| | reception. |
| | |
| Event Count | The number of events that are reported in this |
| | attribute. This field is a 3-byte unsigned |
| | integer. The EID, Timestamp, Record Identifier, |
| | Data Model Type PEN, Data Model Type, Source |
| | Identification Number, Action, Software |
| | Identifier Length, Software Identifier, Software |
| | Locator Length, and Software Locator fields are |
| | repeated, in order, the number of times |
| | indicated in this field. This field value MAY |
| | be 0, in which case there are no instances of |
| | these fields. |
| | |
| Request ID | In the case where this attribute is in direct |
| Copy / | response to a SWIMA Request attribute from a |
| Subscription | SWIMA-PV, this field MUST contain an exact copy |
| ID | of the Request ID field from that SWIMA Request. |
| | In the case where this attribute is sent in |
| | fulfillment of an active subscription, this |
| | field MUST contain the Subscription ID of the |
| | subscription being fulfilled by this attribute. |
| | |
| EID Epoch | The EID Epoch of the Last EID value. This field |
| | is a 4-byte unsigned integer. |
| | |
| Last EID | The EID of the last event recorded by the |
| | SWIMA-PC, or 0 if the SWIMA-PC has no recorded |
| | events. This field contains the EID of the |
| | SWIMA-PC's last recorded change event (which |
| | might or might not be included as an event |
| | record in this attribute). |
| | |
| Last Consulted | The EID of the last event record that was |
| EID | consulted when generating the event record list |
| | included in this attribute. This is different |
| | from the Last EID field value if and only if |
| | this attribute is conveying a partial list of |
| | event records. See Section 3.7.5 for more on |
| | partial lists of event records. |
| | |
| EID | The EID of the event in this event record. |
| | |
| Timestamp | The timestamp associated with the event in this |
| | event record. This timestamp is the SWIMA-PC's |
| | best understanding of when the given event |
| | occurred. Note that this timestamp might be an |
| | estimate. The Timestamp date and time MUST be |
| | represented as an ASCII string that is expressed |
| | in Coordinated Universal Time (UTC) and is |
| | compliant with RFC 3339 [RFC3339], with the |
| | additional restrictions that the 'T' delimiter |
| | and the 'Z' suffix MUST be capitalized and |
| | fractional seconds (time-secfrac) MUST NOT be |
| | included. This field conforms to the date-time |
| | ABNF production from Section 5.6 of RFC 3339, |
| | with the above restrictions. Leap seconds are |
| | permitted, and SWIMA-PVs MUST support them. The |
| | Timestamp string MUST NOT be null terminated or |
| | padded in any way. The length of this field is |
| | always 20 octets. |
| | |
| Record | A 4-byte unsigned integer containing the Record |
| Identifier | Identifier value from a Software Inventory |
| | Evidence Record. |
| | |
| Data Model | A 3-byte unsigned integer containing the PEN of |
| Type PEN | the organization that assigned the meaning of |
| | the Data Model Type value. |
| | |
| Data Model | A 1-byte unsigned integer containing an |
| Type | identifier number that identifies the data model |
| | of the reported record. |
| | |
| Source | The Source Identifier number associated with the |
| Identification | source for the software installation inventory |
| Number | instance that this event record reported. |
| | |
| Action | The type of event that is recorded in this event |
| | record. Possible values are as follows: 1 = |
| | CREATION - the addition of a record to the |
| | endpoint's Software Inventory Evidence |
| | Collection; 2 = DELETION - the removal of a |
| | record from the endpoint's Software Inventory |
| | Evidence Collection; 3 = ALTERATION - an |
| | alteration that was made to a record within the |
| | endpoint's Software Inventory Evidence |
| | Collection. All other values are reserved for |
| | future use and MUST NOT be used when sending |
| | attributes. In the case where a SWIMA-PV |
| | receives an event record that uses an action |
| | value other than the ones defined here, it MUST |
| | ignore that event record but SHOULD process |
| | other event records in this attribute as normal. |
| | |
| Software | A 2-byte unsigned integer indicating the length, |
| Identifier | in bytes, of the Software Identifier field. |
| Length | |
| | |
| Software | A string containing the Software Identifier |
| Identifier | value from a Software Inventory Evidence Record. |
| | This field value MUST first be normalized to |
| | Network Unicode format, as described in |
| | Section 5.4. This string MUST NOT be null |
| | terminated. |
| | |
| Software | A 2-byte unsigned integer indicating the length, |
| Locator Length | in bytes, of the Software Locator field. |
| | |
| Software | A string containing the Software Locator value. |
| Locator | This field value MUST first be normalized to |
| | Network Unicode format, as described in |
| | Section 5.4, and then encoded as a URI |
| | [RFC3986]. This string MUST NOT be null |
| | terminated. |
+----------------+--------------------------------------------------+
Table 4: Software Identifier Events Attribute Fields
表4：ソフトウェア識別子イベント属性フィールド
The first few fields in the Software Identifier Events attribute mirror those in the Software Identifier Inventory attribute. The primary difference is that instead of conveying an inventory the attribute conveys zero or more event records, consisting of the EID, Timestamp, Record Identifier, Data Model Type PEN, Data Model Type, Source Identification Number, Action, Software Identifier Length, Software Identifier, Software Locator Length, and Software Locator fields of the affected Software Inventory Evidence Record.
ソフトウェアIDイベント属性の最初のいくつかのフィールドは、ソフトウェアIDインベントリ属性のフィールドを反映しています。主な違いは、EID、タイムスタンプ、レコードID、データモデルタイプPEN、データモデルタイプ、ソースID番号、アクション、ソフトウェアID長、ソフトウェアIDで構成される属性を、インベントリを伝達する代わりに0個以上のイベントレコードで伝達することです。 、影響を受けるソフトウェアインベントリエビデンスレコードのSoftware Locator Length、Software Locatorフィールド。
With regard to the Timestamp field, it is important to note that clock skew between the SWIMA-PC and SWIMA-PV as well as between different SWIMA-PCs within an enterprise might make correlation of Timestamp values difficult. This specification does not attempt to resolve clock skew issues, although other mechanisms (which are outside the scope of this specification) do exist to reduce the impact of clock skew and make the timestamp more useful for such correlation. Instead, SWIMA uses the Timestamp value primarily as a means to indicate the amount of time between two events on a single endpoint. For example, by taking the difference of the times for when a record was removed and then subsequently re-added, one can get an indication as to how long the system was without the given record (and thus without the associated software). Since this will involve comparison of Timestamp values all originating on the same system, clock skew between the SWIMA-PC and SWIMA-PV is not an issue. However, if the SWIMA-PC's clock was adjusted between two recorded events, it is possible for such a calculation to lead to misunderstandings regarding the temporal distance between events. Users of this field need to be aware of the possibility for such occurrences. In the case where the Timestamp values of two events appear to contradict the EID ordering of those events (i.e., the later EID has an earlier timestamp), the recipient MUST treat the EID ordering as correct.
タイムスタンプフィールドに関しては、SWIMA-PCとSWIMA-PVの間、および企業内の異なるSWIMA-PC間のクロックスキューにより、タイムスタンプ値の相関が困難になる可能性があることに注意することが重要です。この仕様は、クロックスキューの問題を解決しようとはしていませんが、他のメカニズム（この仕様の範囲外）が存在し、クロックスキューの影響を減らし、タイムスタンプをそのような相関関係にさらに役立ちます。代わりに、SWIMAは主に単一のエンドポイント上の2つのイベント間の時間を示す手段としてタイムスタンプ値を使用します。たとえば、レコードが削除されてから再度追加されたときの時間差をとることにより、システムに指定されたレコードがない（したがって関連するソフトウェアがない）期間を示すことができます。これには、すべて同じシステムで発生したタイムスタンプ値の比較が含まれるため、SWIMA-PCとSWIMA-PV間のクロックスキューは問題になりません。ただし、SWIMA-PCのクロックが2つの記録されたイベント間で調整された場合、そのような計算により、イベント間の時間的な距離に関する誤解が生じる可能性があります。このフィールドのユーザーは、そのような発生の可能性を認識する必要があります。 2つのイベントのTimestamp値がそれらのイベントのEID順序と矛盾しているように見える場合（つまり、より遅いEIDはより早いタイムスタンプを持つ）、受信者はEID順序を正しいものとして扱わなければなりません（MUST）。
All events recorded in a Software Identifier Events attribute are required to be part of the same EID Epoch. Specifically, all such reported events MUST have an EID that is from the same EID Epoch and that is the same as the EID Epoch of the Last EID and Last Consulted EID values. The SWIMA-PC MUST NOT report events with EIDs from different EID Epochs.
ソフトウェアIDイベント属性に記録されるすべてのイベントは、同じEIDエポックの一部である必要があります。具体的には、そのような報告されたすべてのイベントには、同じEIDエポックからのEIDがあり、これは、Last EIDおよびLast Consulted EID値のEIDエポックと同じである必要があります。 SWIMA-PCは、異なるEIDエポックからのEIDを持つイベントを報告してはなりません。
The Last Consulted EID field contains the EID of the last event record considered for inclusion in this attribute. If this attribute contains a partial event set (as described in Section 3.7.5), this field value will be less than the Last EID value; if this attribute contains a complete event set, the Last EID and Last Consulted EID values are identical.
[Last Consulted EID]フィールドには、この属性に含めると考えられる最後のイベントレコードのEIDが含まれています。この属性に部分的なイベントセットが含まれている場合（セクション3.7.5で説明）、このフィールドの値はLast EIDの値よりも小さくなります。この属性に完全なイベントセットが含まれている場合、Last EIDとLast Consulted EIDの値は同じです。
If multiple events are sent in a Software Identifier Events attribute, the order in which they appear within the attribute is not significant. The EIDs associated with them are used for ordering the indicated events appropriately. Also note that a single software record might be reported multiple times in an attribute, such as if multiple events involving the associated record were being reported.
複数のイベントがソフトウェアIDイベント属性で送信される場合、属性内でのそれらの出現順序は重要ではありません。それらに関連付けられたEIDは、示されたイベントを適切に順序付けるために使用されます。また、関連付けられたレコードに関連する複数のイベントが報告されている場合など、1つのソフトウェアレコードが属性で複数回報告される場合があることに注意してください。
A SWIMA-PC sends this attribute to a SWIMA-PV to convey a list of inventory records. A SWIMA-PV MUST NOT send this attribute. The SWIMA-PC sends this attribute either (1) in fulfillment of an existing subscription where the establishing request has a Result Type of 0 and the Earliest EID is zero or (2) in direct response to a SWIMA Request attribute where the Result Type is 0 and the Earliest EID is zero.
SWIMA-PCはこの属性をSWIMA-PVに送信して、在庫レコードのリストを伝えます。 SWIMA-PVはこの属性を送信してはなりません。 SWIMA-PCは、（1）確立要求の結果タイプが0で、Earliest EIDがゼロである既存のサブスクリプションの履行で、または（2）結果タイプがSWIMA要求属性に直接応答して、この属性を送信します。 0で、Earliest EIDはゼロです。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID Copy / Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EID Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SUB-BLOCK (Repeated "Record Count" times) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Software Inventory Attribute
図12：ソフトウェアインベントリ属性
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Model Type PEN |Data Model Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Id Num | Reserved | Software Identifier Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Locator Length |Software Locator (variable len)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Software Inventory Attribute SUB-BLOCK
図13：ソフトウェアインベントリ属性のサブブロック
+----------------+--------------------------------------------------+
| Field | Description |
+----------------+--------------------------------------------------+
| Flags: Bit 0 - | In the case that this attribute is sent in |
| Subscription | fulfillment of a subscription, this bit MUST be |
| Fulfillment | set (1). In the case that this attribute is a |
| | direct response to a SWIMA Request, this bit |
| | MUST be unset (0). |
| | |
| Flags: Bits | Reserved for future use. This field MUST be set |
| 1-7 - Reserved | to zero on transmission and ignored upon |
| | reception. |
| | |
| Record Count | The number of records that follow. This field |
| | is a 3-byte unsigned integer. The Record |
| | Identifier, Data Model Type PEN, Data Model |
| | Type, Source Identification Number, Reserved, |
| | Software Identifier Length, Software Identifier, |
| | Software Locator Length, Software Locator, |
| | Record Length, and Record fields are repeated, |
| | in order, the number of times indicated in this |
| | field. This field value MAY be 0, in which case |
| | there are no instances of these fields. |
| | |
| Request ID | In the case where this attribute is in direct |
| Copy / | response to a SWIMA Request attribute from a |
| Subscription | SWIMA-PV, this field MUST contain an exact copy |
| ID | of the Request ID field from that SWIMA Request. |
| | In the case where this attribute is sent in |
| | fulfillment of an active subscription, this |
| | field MUST contain the Subscription ID of the |
| | subscription being fulfilled by this attribute. |
| | |
| EID Epoch | The EID Epoch of the Last EID value. This field |
| | is a 4-byte unsigned integer. |
| | |
| Last EID | The EID of the last event recorded by the |
| | SWIMA-PC, or 0 if the SWIMA-PC has no recorded |
| | events. This field is a 4-byte unsigned |
| | integer. |
| | |
| Record | A 4-byte unsigned integer containing the Record |
| Identifier | Identifier value from a Software Inventory |
| | Evidence Record. |
| | |
| Data Model | A 3-byte unsigned integer containing the PEN of |
| Type PEN | the organization that assigned the meaning of |
| | the Data Model Type value. |
| | |
| Data Model | A 1-byte unsigned integer containing an |
| Type | identifier number that identifies the data model |
| | of the reported record. |
| | |
| Source | The Source Identifier number associated with the |
| Identification | source from which this software installation |
| Number | inventory instance was reported. |
| | |
| Reserved | Reserved for future use. This field MUST be set |
| | to zero on transmission and ignored upon |
| | reception. |
| | |
| Software | A 2-byte unsigned integer indicating the length, |
| Identifier | in bytes, of the Software Identifier field. |
| Length | |
| | |
| Software | A string containing the Software Identifier |
| Identifier | value from a Software Inventory Evidence Record. |
| | This field value MUST first be normalized to |
| | Network Unicode format, as described in |
| | Section 5.4. This string MUST NOT be null |
| | terminated. |
| | |
| Software | A 2-byte unsigned integer indicating the length, |
| Locator Length | in bytes, of the Software Locator field. |
| | |
| Software | A string containing the Software Locator value. |
| Locator | This field value MUST first be normalized to |
| | Network Unicode format, as described in |
| | Section 5.4, and then encoded as a URI |
| | [RFC3986]. This string MUST NOT be null |
| | terminated. |
| | |
| Record Length | A 4-byte unsigned integer indicating the length, |
| | in bytes, of the Record field. |
| | |
| Record | A Software Inventory Evidence Record expressed |
| | as a string. The record MUST be converted and |
| | normalized to Network Unicode format, as |
| | described in Section 5.4. This string MUST NOT |
| | be null terminated. |
+----------------+--------------------------------------------------+
Table 5: Software Inventory Attribute Fields
表5：ソフトウェアインベントリ属性フィールド
The Software Inventory attribute contains some number of Software Inventory Evidence Records along with the core response attribute fields. Given that the size of records can vary considerably, the length of this attribute is highly variable and, if transmitting a complete inventory, can be extremely large. To avoid unnecessarily overburdening the network, enterprises might wish to constrain the use of Software Inventory attributes to targeted requests.
ソフトウェアインベントリ属性には、コアレスポンス属性フィールドとともにいくつかのソフトウェアインベントリエビデンスレコードが含まれています。レコードのサイズはかなり変動する可能性があるため、この属性の長さは非常に変動しやすく、完全なインベントリを送信する場合、非常に大きくなる可能性があります。不必要にネットワークに過負荷をかけないようにするために、企業はソフトウェアインベントリ属性の使用を対象を絞った要求に制限したい場合があります。
When copying a Software Inventory Evidence Record into the Record field, the record MUST be converted and normalized to use Network Unicode format prior to its inclusion in the Record field.
ソフトウェアインベントリエビデンスレコードをレコードフィールドにコピーする場合、レコードは、レコードフィールドに含める前に、ネットワークUnicode形式を使用するように変換および正規化する必要があります。
A SWIMA-PC sends this attribute to a SWIMA-PV to convey a list of events that include Software Inventory Evidence Records. A SWIMA-PV MUST NOT send this attribute. The SWIMA-PC sends this attribute either (1) in fulfillment of an existing subscription where the establishing request has a Result Type of 0 and the Earliest EID is non-zero or (2) in direct response to a SWIMA Request attribute where the Result Type is 0 and the Earliest EID is non-zero.
SWIMA-PCはこの属性をSWIMA-PVに送信して、ソフトウェアインベントリエビデンスレコードを含むイベントのリストを伝えます。 SWIMA-PVはこの属性を送信してはなりません。 SWIMA-PCがこの属性を送信するのは、（1）確立要求の結果タイプが0で、Earliest EIDがゼロ以外である既存のサブスクリプションの履行、または（2）結果がSWIMA要求属性に直接応答する場合です。タイプは0で、Earliest EIDはゼロ以外です。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Event Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID Copy / Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EID Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Consulted EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SUB-BLOCK (Repeated "Event Count" times) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: Software Events Attribute
図14：ソフトウェアイベント属性
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- -+
| Timestamp |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Model Type PEN |Data Model Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Id Num | Action | Software Identifier Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Identifier (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Locator Length |Software Locator (variable len)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Record (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Software Events Attribute SUB-BLOCK
図15：ソフトウェアイベント属性SUB-BLOCK
+----------------+--------------------------------------------------+
| Field | Description |
+----------------+--------------------------------------------------+
| Flags: Bit 0 - | In the case that this attribute is sent in |
| Subscription | fulfillment of a subscription, this bit MUST be |
| Fulfillment | set (1). In the case that this attribute is a |
| | direct response to a SWIMA Request, this bit |
| | MUST be unset (0). |
| | |
| Flags: Bits | Reserved for future use. This field MUST be set |
| 1-7 - Reserved | to zero on transmission and ignored upon |
| | reception. |
| | |
| Event Count | The number of events being reported in this |
| | attribute. This field is a 3-byte unsigned |
| | integer. The EID, Timestamp, Record Identifier, |
| | Data Model Type PEN, Data Model Type, Source |
| | Identification Number, Action, Software |
| | Identifier Length, Software Identifier, Software |
| | Locator Length, Software Locator, Record Length, |
| | and Record fields are repeated, in order, the |
| | number of times indicated in this field. This |
| | field value MAY be 0, in which case there are no |
| | instances of these fields. |
| | |
| Request ID | In the case where this attribute is in direct |
| Copy / | response to a SWIMA Request attribute from a |
| Subscription | SWIMA-PV, this field MUST contain an exact copy |
| ID | of the Request ID field from that SWIMA Request. |
| | In the case where this attribute is sent in |
| | fulfillment of an active subscription, this |
| | field MUST contain the Subscription ID of the |
| | subscription being fulfilled by this attribute. |
| | |
| EID Epoch | The EID Epoch of the Last EID value. This field |
| | is a 4-byte unsigned integer. |
| | |
| Last EID | The EID of the last event recorded by the |
| | SWIMA-PC, or 0 if the SWIMA-PC has no recorded |
| | events. This field contains the EID of the |
| | SWIMA-PC's last recorded change event (which |
| | might or might not be included as an event |
| | record in this attribute). |
| | |
| Last Consulted | The EID of the last event record that was |
| EID | consulted when generating the event record list |
| | included in this attribute. This is different |
| | from the Last EID field value if and only if |
| | this attribute is conveying a partial list of |
| | event records. See Section 3.7.5 for more on |
| | partial lists of event records. |
| | |
| EID | The EID of the event in this event record. |
| | |
| Timestamp | The timestamp associated with the event in this |
| | event record. This timestamp is the SWIMA-PC's |
| | best understanding of when the given event |
| | occurred. Note that this timestamp might be an |
| | estimate. The Timestamp date and time MUST be |
| | represented as an ASCII string that is expressed |
| | in Coordinated Universal Time (UTC) and is |
| | compliant with RFC 3339 [RFC3339], with the |
| | additional restrictions that the 'T' delimiter |
| | and the 'Z' suffix MUST be capitalized and |
| | fractional seconds (time-secfrac) MUST NOT be |
| | included. This field conforms to the date-time |
| | ABNF production from Section 5.6 of RFC 3339, |
| | with the above restrictions. Leap seconds are |
| | permitted, and SWIMA-PVs MUST support them. The |
| | Timestamp string MUST NOT be null terminated or |
| | padded in any way. The length of this field is |
| | always 20 octets. |
| | |
| Record | A 4-byte unsigned integer containing the Record |
| Identifier | Identifier value from a Software Inventory |
| | Evidence Record. |
| | |
| Data Model | A 3-byte unsigned integer containing the PEN of |
| Type PEN | the organization that assigned the meaning of |
| | the Data Model Type value. |
| | |
| Data Model | A 1-byte unsigned integer containing an |
| Type | identifier number that identifies the data model |
| | of the reported record. |
| | |
| Source | The Source Identifier number associated with the |
| Identification | source for the software installation inventory |
| Number | instance that this event record reported. |
| | |
| Action | The type of event that is recorded in this event |
| | record. Possible values are as follows: 1 = |
| | CREATION - the addition of a record to the |
| | endpoint's Software Inventory Evidence |
| | Collection; 2 = DELETION - the removal of a |
| | record from the endpoint's Software Inventory |
| | Evidence Collection; 3 = ALTERATION - an |
| | alteration that was made to a record within the |
| | endpoint's Software Inventory Evidence |
| | Collection. All other values are reserved for |
| | future use and MUST NOT be used when sending |
| | attributes. In the case where a SWIMA-PV |
| | receives an event record that uses an action |
| | value other than the ones defined here, it MUST |
| | ignore that event record but SHOULD process |
| | other event records in this attribute as normal. |
| | |
| Software | A 2-byte unsigned integer indicating the length, |
| Identifier | in bytes, of the Software Identifier field. |
| Length | |
| | |
| Software | A string containing the Software Identifier |
| Identifier | value from a Software Inventory Evidence Record. |
| | This field value MUST first be normalized to |
| | Network Unicode format, as described in |
| | Section 5.4. This string MUST NOT be null |
| | terminated. |
| | |
| Software | A 2-byte unsigned integer indicating the length, |
| Locator Length | in bytes, of the Software Locator field. |
| | |
| Software | A string containing the Software Locator value. |
| Locator | This field value MUST first be normalized to |
| | Network Unicode format, as described in |
| | Section 5.4, and then encoded as a URI |
| | [RFC3986]. This string MUST NOT be null |
| | terminated. |
| | |
| Record Length | A 4-byte unsigned integer indicating the length, |
| | in bytes, of the Record field. |
| | |
| Record | A Software Inventory Evidence Record expressed |
| | as a string. The record MUST be converted and |
| | normalized to Network Unicode format, as |
| | described in Section 5.4. This string MUST NOT |
| | be null terminated. |
+----------------+--------------------------------------------------+
Table 6: Software Events Attribute Fields
表6：ソフトウェアイベント属性フィールド
The fields of this attribute are used in the same way as the corresponding fields of the previous attributes. As with the Software Inventory attribute, a Software Events attribute can be quite large if many events have occurred following the event indicated by a request's Earliest EID. As such, it is recommended that the SWIMA Request attributes only request that full records be sent (Result Type set to zero) in a targeted request, thus constraining the response just to records that match a given set of Software Identifiers.
この属性のフィールドは、前の属性の対応するフィールドと同じ方法で使用されます。ソフトウェアインベントリ属性と同様に、要求の最も早いEIDで示されるイベントの後に多くのイベントが発生した場合、ソフトウェアイベント属性は非常に大きくなる可能性があります。そのため、SWIMAリクエスト属性は、ターゲットリクエストで完全なレコードの送信（結果タイプをゼロに設定）のみをリクエストすることをお勧めします。これにより、特定のソフトウェア識別子のセットと一致するレコードのみにレスポンスを制限します。
As with the Software Identifier Events attribute, this attribute MUST only contain event records with EIDs coming from the current EID Epoch of the SWIMA-PC.
ソフトウェア識別子イベント属性と同様に、この属性には、SWIMA-PCの現在のEIDエポックからのEIDを持つイベントレコードのみを含める必要があります。
As with the Software Inventory attribute, the SWIMA-PC MUST perform conversion and normalization of the record.
ソフトウェアインベントリ属性と同様に、SWIMA-PCはレコードの変換と正規化を実行する必要があります。
A SWIMA-PV sends this attribute to a SWIMA-PC to request a list of active subscriptions for which the requesting SWIMA-PV is the subscriber. A SWIMA-PC MUST NOT send this attribute.
SWIMA-PVはこの属性をSWIMA-PCに送信して、要求しているSWIMA-PVがサブスクライバであるアクティブなサブスクリプションのリストを要求します。 SWIMA-PCはこの属性を送信してはなりません。
This attribute has no fields.
この属性にはフィールドがありません。
A SWIMA-PC MUST respond to this attribute by sending a Subscription Status Response attribute (or a PA-TNC Error attribute if it is unable to correctly provide a response).
SWIMA-PCは、サブスクリプションステータス応答属性（または応答を正しく提供できない場合はPA-TNCエラー属性）を送信して、この属性に応答する必要があります。
A SWIMA-PC sends this attribute to a SWIMA-PV to report the list of active subscriptions for which the receiving SWIMA-PV is the subscriber. A SWIMA-PV MUST NOT send this attribute.
SWIMA-PCはこの属性をSWIMA-PVに送信して、受信SWIMA-PVがサブスクライバーであるアクティブなサブスクリプションのリストを報告します。 SWIMA-PVはこの属性を送信してはなりません。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Flags | Subscription Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SUB-BLOCK (Repeated "Subscription Record Count" times) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Subscription Status Response Attribute
図16：サブスクリプションステータスレスポンス属性
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Software Identifier Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Earliest EID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| SUB-SUB-BLOCK (Repeated "Software Identifier Count" times) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Subscription Status Response Attribute SUB-BLOCK
図17：サブスクリプションステータス応答属性SUB-BLOCK
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Identifier Length | Software Identifier (var len) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: Subscription Status Response Attribute SUB-SUB-BLOCK
図18：サブスクリプションステータス応答属性SUB-SUB-BLOCK
+--------------+----------------------------------------------------+
| Field | Description |
+--------------+----------------------------------------------------+
| Status | Reserved for future use. This field MUST be set |
| Flags: Bits | to zero on transmission and ignored upon |
| 0-7 - | reception. |
| Reserved | |
| | |
| Subscription | The number of subscription records that follow. |
| Record Count | This field is a 3-byte unsigned integer. The |
| | Flags, Software Identifier Count, Request ID, and |
| | Earliest EID fields, and zero or more instances of |
| | Software Identifier Length and Software |
| | Identifier, are repeated, in order, the number of |
| | times indicated in this field. (The Software |
| | Identifier Length and Software Identifier fields |
| | within each of these sets of fields are repeated a |
| | number of times equal to the preceding Software |
| | Identifier Count value.) The Subscription Record |
| | Count field value MAY be 0, in which case there |
| | are no instances of these fields. |
| | |
| Flags, | For each active subscription, these fields contain |
| Software | an exact copy of the fields with the corresponding |
| Identifier | name provided in the subscription's establishing |
| Count, | request. |
| Request ID, | |
| Earliest | |
| EID, | |
| Software | |
| Identifier | |
| Length, and | |
| Software | |
| Identifier | |
+--------------+----------------------------------------------------+
Table 7: Subscription Status Response Fields
表7：サブスクリプションステータスの応答フィールド
A Subscription Status Response contains zero or more subscription records. Specifically, it MUST contain one subscription record for each active subscription associated with the party that sent the Subscription Status Request to which this attribute is a response. As described in Section 3.8.2, the SWIMA-PC MUST use the requester's Connection ID and its Posture Validator Identifier to determine which subscriptions are associated with the requester.
Subscription Status Responseには、0個以上のサブスクリプションレコードが含まれています。具体的には、この属性が応答であるサブスクリプションステータスリクエストを送信したパーティに関連付けられたアクティブなサブスクリプションごとに1つのサブスクリプションレコードを含める必要があります。セクション3.8.2で説明されているように、SWIMA-PCはリクエスタの接続IDとそのポスチャバリデータ識別子を使用して、リクエスタに関連付けられているサブスクリプションを特定する必要があります。
A SWIMA-PC MUST send a Subscription Status Response attribute in response to a Subscription Status Request attribute, except in cases where the SWIMA-PC experiences an error condition that prevents it from correctly populating the Subscription Status Response attribute (in which case it MUST respond with a PA-TNC Error attribute appropriate to the type of error experienced). If there are no active subscriptions associated with the requesting party, the Subscription Status Response attribute will consist only of its Status Flags field and a Subscription Record Count field with a value of 0, and no additional fields.
SWIMA-PCがサブスクリプションステータスリクエスト属性に応答してサブスクリプションステータスレスポンス属性を送信しなければならない（ただし、SWIMA-PCがサブスクリプションステータスレスポンス属性に正しく入力できないエラー条件が発生した場合を除く）。発生したエラーのタイプに適したPA-TNCエラー属性を含む）。要求側に関連付けられたアクティブなサブスクリプションがない場合、サブスクリプションステータス応答属性は、そのステータスフラグフィールドと値0のサブスクリプションレコード数フィールドのみで構成され、追加のフィールドはありません。
Each subscription record included in a Subscription Status Response attribute duplicates the fields of the SWIMA Request attribute that was the establishing request of a subscription. Note that the Request ID field in the record captures the Subscription ID associated with the given subscription record (since the Subscription ID is the same as the Request ID of the establishing request). Note also that if the establishing request is targeted, then its Record Count field will be non-zero and, within that subscription record, the Software Identifier Length and Software Identifier fields are repeated, in order, the number of times indicated in the Record Count field. As such, each subscription record can be different sizes. If the establishing request is not targeted (Record Count field is 0), the subscription record has no Software Identifier Length or Software Identifier fields.
Subscription Status Response属性に含まれる各サブスクリプションレコードは、サブスクリプションの確立要求であったSWIMA Request属性のフィールドを複製します。レコードのリクエストIDフィールドは、指定されたサブスクリプションレコードに関連付けられたサブスクリプションIDを取得することに注意してください（サブスクリプションIDは確立リクエストのリクエストIDと同じであるため）。また、確立要求がターゲットの場合、そのレコードカウントフィールドはゼロではなく、そのサブスクリプションレコード内で、ソフトウェア識別子の長さとソフトウェア識別子フィールドが、レコードカウントに示された回数順に繰り返されます。フィールド。そのため、各サブスクリプションレコードは異なるサイズにすることができます。確立要求がターゲットにされていない場合（レコード数フィールドが0）、サブスクリプションレコードにはソフトウェア識別子の長さまたはソフトウェア識別子フィールドがありません。
When a SWIMA-PV compares the information received in a Subscription Status Response to its own records of active subscriptions, it should be aware that the SWIMA-PC might be unable to distinguish this SWIMA-PV from other SWIMA-PVs on the same NEA Server. As a result, it is possible that the SWIMA-PC will report more subscription records than the SWIMA-PV recognizes. For this reason, SWIMA-PVs SHOULD NOT automatically assume that extra subscriptions reported in a Subscription Status Response indicate a problem.
SWIMA-PVがサブスクリプションステータスレスポンスで受信した情報をアクティブなサブスクリプションの独自のレコードと比較する場合、SWIMA-PCがこのSWIMA-PVを同じNEAサーバー上の他のSWIMA-PVと区別できない場合があることに注意してください。 。その結果、SWIMA-PCがSWIMA-PVが認識するよりも多くのサブスクリプションレコードを報告する可能性があります。このため、SWIMA-PVは、サブスクリプションステータス応答で報告された追加のサブスクリプションが問題を示しているとは自動的に想定すべきではありません（SHOULD NOT）。
A SWIMA-PV sends this attribute to a SWIMA-PC to request metadata about sources that the SWIMA-PC is using to collect software inventory information. A SWIMA-PC MUST NOT send this attribute.
SWIMA-PVはこの属性をSWIMA-PCに送信して、SWIMA-PCがソフトウェアインベントリ情報の収集に使用しているソースに関するメタデータを要求します。 SWIMA-PCはこの属性を送信してはなりません。
This attribute has no fields.
この属性にはフィールドがありません。
A SWIMA-PC MUST respond to this attribute by sending a Source Metadata Response attribute (or a PA-TNC Error attribute if it is unable to correctly provide a response).
SWIMA-PCは、ソースメタデータ応答属性（または応答を正しく提供できない場合はPA-TNCエラー属性）を送信することにより、この属性に応答する必要があります。
A SWIMA-PC sends this attribute to a SWIMA-PV to provide descriptive metadata about the sources of software inventory information used by the SWIMA-PC. A SWIMA-PV MUST NOT send this attribute.
SWIMA-PCはこの属性をSWIMA-PVに送信して、SWIMA-PCが使用するソフトウェアインベントリ情報のソースに関する記述メタデータを提供します。 SWIMA-PVはこの属性を送信してはなりません。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Source Count | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| SUB-BLOCK (Repeated "Source Count" times) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 19: Source Metadata Response Attribute
図19：ソースメタデータレスポンス属性
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Id Num | Metadata Length | Metadata (var)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: Source Metadata Response Attribute SUB-BLOCK
図20：ソースメタデータレスポンス属性SUB-BLOCK
+----------------+--------------------------------------------------+
| Field | Description |
+----------------+--------------------------------------------------+
| Reserved | Reserved for future use. This field MUST be set |
| | to zero on transmission and ignored upon |
| | reception. |
| | |
| Source Count | The number of source records that follow. The |
| | Source Identification Number, Metadata Length, |
| | and Metadata fields are repeated, in order, the |
| | number of times indicated by this field. This |
| | field MAY be 0, in which case no fields follow |
| | (but this would only be done to indicate that |
| | the SWIMA-PC has no active sources; this would |
| | not be a typical situation). |
| | |
| Source | The Source Identifier number associated with the |
| Identification | described source for any communications with the |
| Number | recipient SWIMA-PV. |
| | |
| Metadata | A 2-byte unsigned integer indicating the length, |
| Length | in bytes, of the Metadata field. |
| | |
| Metadata | A string containing descriptive metadata about |
| | the indicated data source. This string MUST NOT |
| | be null terminated. |
+----------------+--------------------------------------------------+
Table 8: Source Metadata Response Fields
表8：ソースメタデータレスポンスフィールド
A Source Metadata Response attribute contains zero or more records, each describing one of the data sources the SWIMA-PC uses to collect software inventory information. It SHOULD contain one metadata record for each source that the SWIMA-PC uses. (There might be reasons not to inform certain SWIMA-PVs of the presence of certain data sources.) The attribute MUST contain a metadata record for each source that has been identified in inventory or event messages to the given SWIMA-PV.
ソースメタデータレスポンス属性には0個以上のレコードが含まれ、それぞれのレコードはSWIMA-PCがソフトウェアインベントリ情報を収集するために使用するデータソースの1つを記述します。 SWIMA-PCが使用するソースごとに1つのメタデータレコードを含める必要があります。 （特定のデータソースの存在を特定のSWIMA-PVに通知しない理由がある場合があります。）属性には、特定のSWIMA-PVのインベントリまたはイベントメッセージで識別された各ソースのメタデータレコードを含める必要があります。
A SWIMA-PC MUST send a Source Metadata Response attribute in response to a Source Metadata Request attribute, except in cases where the SWIMA-PC experiences an error condition that prevents it from correctly populating the Source Metadata Response attribute (in which case it MUST respond with a PA-TNC Error attribute appropriate to the type of error experienced).
SWIMA-PCは、ソースメタデータリクエスト属性に応答して、ソースメタデータレスポンス属性を送信する必要があります。ただし、SWIMA-PCでエラー状態が発生し、ソースメタデータレスポンス属性に正しく入力できない場合は例外です（この場合、応答する必要があります）。発生したエラーのタイプに適したPA-TNCエラー属性を含む）。
The Source Count field indicates how many source metadata records are included in the attribute. Each included record consists of a Source Identification Number field, a Metadata Length field, and a Metadata field.
Source Countフィールドは、属性に含まれるソースメタデータレコードの数を示します。含まれる各レコードは、ソース識別番号フィールド、メタデータ長フィールド、およびメタデータフィールドで構成されます。
The Source Identification Number field in the Source Metadata Response attribute corresponds to the Source Identification Number field in inventory and event messages. In the case where (1) the Source Identification Number value in this attribute matches a Source Identification Number field in an inventory or event record and (2) both the Source Metadata Response and the inventory or event record were sent to the same SWIMA-PV, the source described in the Metadata field MUST be the same source that provided the inventory or event record associated with this Source Identifier. Recall that a SWIMA-PC MAY use different Source Identification Number associations with different SWIMA-PVs. As such, the association between a Source Identification Number and the conveyed metadata is also only meaningful for communications between the sending SWIMA-PC and receiving SWIMA-PV. When sending to a given SWIMA-PV, the SWIMA-PC MUST use the recipient SWIMA-PV's Source Identification Number associations.
ソースメタデータレスポンス属性のソース識別番号フィールドは、インベントリおよびイベントメッセージのソース識別番号フィールドに対応します。 （1）この属性のソース識別番号の値がインベントリまたはイベントレコードのソース識別番号フィールドと一致し、（2）ソースメタデータ応答とインベントリまたはイベントレコードの両方が同じSWIMA-PVに送信された場合、メタデータフィールドに記述されたソースは、このソース識別子に関連付けられたインベントリまたはイベントレコードを提供したソースと同じでなければなりません。 SWIMA-PCは異なるSWIMA-PVと異なるソースID番号の関連付けを使用してもよいことを思い出してください。そのため、ソース識別番号と伝達されるメタデータの間の関連付けは、送信側のSWIMA-PCと受信側のSWIMA-PVの間の通信に対してのみ意味があります。特定のSWIMA-PVに送信する場合、SWIMA-PCは受信者SWIMA-PVの送信元識別番号の関連付けを使用する必要があります。
The Metadata Length field indicates the length, in bytes, of the Metadata field. The Metadata field contains information about the indicated data source. This specification does not dictate a format for the contents of the Metadata field. This field MAY include machine-readable information. For broadest utility, the Metadata field SHOULD include human-readable, descriptive information about the data source.
メタデータ長フィールドは、メタデータフィールドの長さをバイト単位で示します。 Metadataフィールドには、示されたデータソースに関する情報が含まれます。この仕様は、メタデータフィールドの内容の形式を規定していません。このフィールドには、機械で読み取り可能な情報が含まれる場合があります。最も広いユーティリティの場合、メタデータフィールドには、データソースに関する人間が読める記述的な情報を含める必要があります（SHOULD）。
The PA-TNC Error attribute is defined in the PA-TNC specification [RFC5792], and its use here conforms to that specification. A PA-TNC Error can be sent due to any error in the PA-TNC exchange and might also be sent in response to error conditions specific to the SWIMA exchange. The latter case utilizes error codes defined below.
PA-TNCエラー属性はPA-TNC仕様[RFC5792]で定義されており、ここでの使用はその仕様に準拠しています。 PA-TNCエラーは、PA-TNC交換のエラーが原因で送信される可能性があり、SWIMA交換に固有のエラー条件に応じて送信される場合もあります。後者の場合は、以下に定義されているエラーコードを利用します。
A PA-TNC Error MUST be sent by a SWIMA-PC in response to a SWIMA Request in the case where the SWIMA-PC encounters a fatal error (i.e., an error that prevents further processing of an exchange) relating to the attribute exchange. A SWIMA-PV MUST NOT send this attribute. In the case where the SWIMA-PV experiences a fatal error, it MUST handle the error without sending a PA-TNC Error attribute. The SWIMA-PV MAY take other actions in response to the error, such as logging the cause of the error or even taking actions to isolate the endpoint.
SWIMA-PCが属性交換に関連する致命的なエラー（つまり、交換のさらなる処理を妨げるエラー）に遭遇した場合、SWIMA-PCによってPA-TNCエラーを送信する必要があります。 SWIMA-PVはこの属性を送信してはなりません。 SWIMA-PVで致命的なエラーが発生した場合、PA-TNCエラー属性を送信せずにエラーを処理する必要があります。 SWIMA-PVは、エラーの原因をログに記録したり、エンドポイントを分離するアクションを実行したりするなど、エラーに応答して他のアクションを実行する場合があります。
A PA-TNC Error attribute is sent instead of a SWIMA Response attribute when certain issues prevent the reliable creation of a SWIMA Response. As such, a SWIMA-PC MUST NOT send both a PA-TNC Error attribute and a SWIMA Response attribute in response to a single SWIMA Request attribute.
特定の問題がSWIMA応答の信頼できる作成を妨げる場合、SWIMA応答属性の代わりにPA-TNCエラー属性が送信されます。そのため、SWIMA-PCは、単一のSWIMA要求属性に応答して、PA-TNCエラー属性とSWIMA応答属性の両方を送信してはなりません（MUST NOT）。
Table 9 lists the error code values for the PA-TNC Error attribute that are specific to the SWIMA exchange. Error codes are shown in both hexadecimal and decimal format. In all of these cases, the Error Code Vendor ID field MUST be set to 0x000000, corresponding to the IETF SMI PEN. The error information structures for each error code are described in the following subsections.
表9に、SWIMA交換に固有のPA-TNCエラー属性のエラーコード値を示します。エラーコードは、16進数と10進数の両方の形式で表示されます。これらすべてのケースで、エラーコードベンダーIDフィールドは、IETF SMI PENに対応する0x000000に設定する必要があります。各エラーコードのエラー情報構造については、次のサブセクションで説明します。
Note that a message with a SWIMA attribute might also result in an error condition covered by the IETF Standard PA-TNC Error Codes defined in Section 4.2.8 of [RFC5792]. For example, a SWIMA attribute might have an invalid parameter, leading to an error code of "Invalid Parameter". In this case, the SWIMA-PC MUST use the appropriate PA-TNC Error Code value as defined in Section 4.2.8 of [RFC5792].
SWIMA属性を持つメッセージは、[RFC5792]のセクション4.2.8で定義されているIETF標準のPA-TNCエラーコードでカバーされるエラー状態になることもあります。たとえば、SWIMA属性に無効なパラメーターが含まれていて、「無効なパラメーター」のエラーコードが発生する場合があります。この場合、SWIMA-PCは、[RFC5792]のセクション4.2.8で定義されている適切なPA-TNCエラーコード値を使用する必要があります。
+----------------+--------------------------------------------------+
| Error Code | Description |
| Value | |
+----------------+--------------------------------------------------+
| 0x00000004 (4) | SWIMA_ERROR. This indicates a fatal error |
| | (i.e., an error that precludes the creation of a |
| | suitable response attribute) other than the |
| | errors described below but still specific to the |
| | processing of SWIMA attributes. The Description |
| | field SHOULD contain additional diagnostic |
| | information. |
| | |
| 0x00000005 (5) | SWIMA_SUBSCRIPTION_DENIED_ERROR. This indicates |
| | that the SWIMA-PC denied the SWIMA-PV's request |
| | to establish a subscription. The Description |
| | field SHOULD contain additional diagnostic |
| | information. |
| | |
| 0x00000006 (6) | SWIMA_RESPONSE_TOO_LARGE_ERROR. This indicates |
| | that the SWIMA-PC's response to the SWIMA-PV's |
| | request was too large to be serviced. The error |
| | information structure indicates the largest |
| | possible size of a response supported by the |
| | SWIMA-PC (see Section 5.15.2). The Description |
| | field SHOULD contain additional diagnostic |
| | information. |
| | |
| 0x00000007 (7) | SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR. This |
| | indicates that the SWIMA-PC experienced an error |
| | while fulfilling a given subscription. The |
| | error information includes the Subscription ID |
| | of the relevant subscription, as well as a |
| | sub-error that describes the nature of the error |
| | the SWIMA-PC experienced. The SWIMA-PC and |
| | SWIMA-PV MUST treat the identified subscription |
| | as cancelled. |
| | |
| 0x00000008 (8) | SWIMA_SUBSCRIPTION_ID_REUSE_ERROR. This |
| | indicates that the SWIMA-PC received a SWIMA |
| | Request from a given SWIMA-PV where the Request |
| | ID of that SWIMA Request is currently used as |
| | the Subscription ID of an active subscription |
| | with that SWIMA-PV. This error does not cancel |
| | the identified subscription. |
+----------------+--------------------------------------------------+
Table 9: PA-TNC Error Codes for SWIMA
表9：SWIMAのPA-TNCエラーコード
The following subsections describe the structures present in the error information fields. Note that all error structures include a variable-length field but do not include any fields indicating the length of those fields. A length field is unnecessary because all other fields in the PA-TNC Error attribute are of fixed length, and thus the length of the variable-length field can be found by subtracting the size of these fixed-length fields from the PA-TNC Attribute Length field in the PA-TNC Attribute Header.
以下のサブセクションでは、エラー情報フィールドに存在する構造について説明します。すべてのエラー構造には可変長フィールドが含まれていますが、それらのフィールドの長さを示すフィールドは含まれていません。 PA-TNCエラー属性の他のすべてのフィールドは固定長であるため、長さフィールドは不要です。したがって、可変長フィールドの長さは、PA-TNC属性からこれらの固定長フィールドのサイズを差し引くことで求められます。 PA-TNC属性ヘッダーの長さフィールド。
5.15.1. SWIMA_ERROR, SWIMA_SUBSCRIPTION_DENIED_ERROR, and SWIMA_SUBSCRIPTION_ID_REUSE_ERROR Information
5.15.1. SWIMA_ERROR、SWIMA_SUBSCRIPTION_DENIED_ERROR、およびSWIMA_SUBSCRIPTION_ID_REUSE_ERROR情報
The SWIMA_ERROR error code indicates that the sender (the SWIMA-PC) has encountered an error that is related to the processing of a SWIMA Request attribute but that is not covered by SWIMA error codes that are more specific. The SWIMA_SUBSCRIPTION_DENIED_ERROR is used when the SWIMA-PV sends a request to establish a subscription or clear all subscriptions from the given SWIMA-PV but the SWIMA-PC is unable or unwilling to comply with this request. The SWIMA_SUBSCRIPTION_ID_REUSE_ERROR is used when the SWIMA-PC receives a SWIMA Request whose Request ID duplicates a Subscription ID of an active subscription with the request's sender. All of these error codes use the following error information structure.
SWIMA_ERRORエラーコードは、送信者（SWIMA-PC）がSWIMA要求属性の処理に関連するエラーを検出したが、より具体的なSWIMAエラーコードではカバーされないことを示しています。 SWIMA-PVがサブスクリプションを確立する要求を送信するか、指定されたSWIMA-PVからすべてのサブスクリプションをクリアするが、SWIMA-PCがこの要求に準拠できない、または同意しない場合、SWIMA_SUBSCRIPTION_DENIED_ERRORが使用されます。 SWIMA_SUBSCRIPTION_ID_REUSE_ERRORは、要求IDがアクティブなサブスクリプションのサブスクリプションIDと要求の送信者と重複する要求IDを持つSWIMA要求を受信したときに使用されます。これらのエラーコードはすべて、次のエラー情報構造を使用します。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Copy of Request ID / Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Description (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: SWIMA_ERROR, SWIMA_SUBSCRIPTION_DENIED_ERROR, and SWIMA_SUBSCRIPTION_ID_REUSE_ERROR Information
図21：SWIMA_ERROR、SWIMA_SUBSCRIPTION_DENIED_ERROR、およびSWIMA_SUBSCRIPTION_ID_REUSE_ERROR情報
+--------------+----------------------------------------------------+
| Field | Description |
+--------------+----------------------------------------------------+
| Copy of | In the case that this error condition is generated |
| Request ID / | in direct response to a SWIMA Request attribute, |
| Subscription | this field MUST contain an exact copy of the |
| ID | Request ID field in the SWIMA Request attribute |
| | that caused this error. In the case that the |
| | attribute in question is generated in fulfillment |
| | of an active subscription, this field MUST contain |
| | the Subscription ID of the subscription for which |
| | the attribute was generated. (This is only |
| | possible if the error code is SWIMA_ERROR, as the |
| | other errors are not generated by subscription |
| | fulfillment.) Note that in the case of failed |
| | subscription fulfillment, the indicated error |
| | appears as a sub-error for a |
| | SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR, as described |
| | in Section 5.15.3. |
| | |
| Description | A UTF-8 [RFC3629] string describing the condition |
| | that caused this error. This field MAY be zero- |
| | length. However, senders SHOULD include some kind |
| | of description in all PA-TNC Error attributes with |
| | these error codes. This field MUST NOT be null |
| | terminated. |
+--------------+----------------------------------------------------+
Table 10: SWIMA_ERROR, SWIMA_SUBSCRIPTION_DENIED_ERROR, and SWIMA_SUBSCRIPTION_ID_REUSE_ERROR Information Fields
表10：SWIMA_ERROR、SWIMA_SUBSCRIPTION_DENIED_ERROR、およびSWIMA_SUBSCRIPTION_ID_REUSE_ERRORの情報フィールド
This error information structure is used with SWIMA_ERROR, SWIMA_SUBSCRIPTION_DENIED_ERROR, and SWIMA_SUBSCRIPTION_ID_REUSE_ERROR status codes to identify the SWIMA Request attribute that precipitated the error condition and to describe the error. The Description field contains text describing the error. The SWIMA-PC MAY encode machine-interpretable information in this field but SHOULD also include a human-readable description of the error, since the receiving SWIMA-PV might not recognize the SWIMA-PC's encoded information.
このエラー情報構造体は、SWIMA_ERROR、SWIMA_SUBSCRIPTION_DENIED_ERROR、およびSWIMA_SUBSCRIPTION_ID_REUSE_ERRORステータスコードと共に使用され、エラー状態を引き起こしたSWIMAリクエスト属性を識別し、エラーを説明します。 Descriptionフィールドには、エラーを説明するテキストが含まれています。 SWIMA-PCはこのフィールドにマシンが解釈可能な情報をエンコードする場合がありますが、受信したSWIMA-PVがSWIMA-PCのエンコードされた情報を認識しない可能性があるため、人間が読み取れるエラーの説明も含める必要があります。
The SWIMA_RESPONSE_TOO_LARGE_ERROR error code indicates that a SWIMA-PC's response to a SWIMA-PV's SWIMA Request attribute was too large to send.
SWIMA_RESPONSE_TOO_LARGE_ERRORエラーコードは、SWIMA-PVのSWIMAリクエスト属性に対するSWIMA-PCの応答が大きすぎて送信できないことを示しています。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Copy of Request ID / Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Maximum Allowed Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Description (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: SWIMA_RESPONSE_TOO_LARGE_ERROR Information
図22：SWIMA_RESPONSE_TOO_LARGE_ERROR情報
+--------------+----------------------------------------------------+
| Field | Description |
+--------------+----------------------------------------------------+
| Copy of | In the case that the attribute in question is |
| Request ID / | generated in direct response to a SWIMA Request, |
| Subscription | this field MUST contain an exact copy of the |
| ID | Request ID field in the SWIMA Request attribute |
| | that caused this error. In the case that the |
| | attribute in question is generated in fulfillment |
| | of an active subscription, this field MUST contain |
| | the Subscription ID of the subscription for which |
| | the attribute was generated. Note that in the |
| | latter case, the SWIMA_RESPONSE_TOO_LARGE_ERROR |
| | appears as a sub-error for a |
| | SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR, as described |
| | in Section 5.15.3. |
| | |
| Maximum | This field MUST contain an unsigned integer |
| Allowed Size | indicating the largest permissible size, in bytes, |
| | of the SWIMA attribute that the SWIMA-PC is |
| | currently willing to send in response to a SWIMA |
| | Request attribute. |
| | |
| Description | A UTF-8 [RFC3629] string describing the condition |
| | that caused this error. This field MAY be zero- |
| | length. However, senders SHOULD include some kind |
| | of description in all PA-TNC Error attributes with |
| | this error code. This field MUST NOT be null |
| | terminated. |
+--------------+----------------------------------------------------+
Table 11: SWIMA_RESPONSE_TOO_LARGE_ERROR Information Fields
表11：SWIMA_RESPONSE_TOO_LARGE_ERRORの情報フィールド
This error structure is used with the SWIMA_RESPONSE_TOO_LARGE_ERROR status code to identify the SWIMA Request attribute that precipitated the error condition and to describe the error. The Maximum Allowed Size field indicates the largest attribute the SWIMA-PC is willing to send in response to a SWIMA Request under the current circumstances. Note that under other circumstances, the SWIMA-PC might be willing to return larger or smaller responses than indicated (such as if the endpoint connects to the NEA Server using a different network protocol). The other fields in this error information structure have the same meanings as corresponding fields in the SWIMA_ERROR and SWIMA_SUBSCRIPTION_DENIED_ERROR information structures.
このエラー構造はSWIMA_RESPONSE_TOO_LARGE_ERRORステータスコードと共に使用され、エラー状態を引き起こしたSWIMAリクエスト属性を識別し、エラーを説明します。 Maximum Allowed Sizeフィールドは、SWIMA-PCが現在の状況下でSWIMA要求に応じて送信する最大の属性を示します。他の状況下では、SWIMA-PCは、示されているよりも大きいまたは小さい応答を返す可能性があることに注意してください（エンドポイントが別のネットワークプロトコルを使用してNEAサーバーに接続する場合など）。このエラー情報構造の他のフィールドは、SWIMA_ERRORおよびSWIMA_SUBSCRIPTION_DENIED_ERROR情報構造の対応するフィールドと同じ意味を持っています。
The SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR error code indicates that the SWIMA-PC encountered an error while fulfilling a subscription. The bytes after the first 4 octets duplicate a PA-TNC Error attribute (as described in Section 4.2.8 of PA-TNC [RFC5792]) that is used to identify the nature of the encountered error.
SWIMA_SUBSCRIPTION_FULFILLMENT_ERRORエラーコードは、サブスクリプションの実行中にSWIMA-PCでエラーが発生したことを示します。最初の4オクテットの後のバイトは、発生したエラーの性質を識別するために使用されるPA-TNCエラー属性（PA-TNC [RFC5792]のセクション4.2.8で説明）を複製します。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subscription ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Sub-error Code Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-error Information (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 23: SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR Information
図23：SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR情報
+--------------+----------------------------------------------------+
| Field | Description |
+--------------+----------------------------------------------------+
| Subscription | This field MUST contain the Subscription ID of the |
| ID | subscription whose fulfillment caused this error. |
| | |
| Reserved | This field MUST contain the value of the Reserved |
| | field of a PA-TNC Error attribute that describes |
| | the error condition encountered during |
| | subscription processing. |
| | |
| Sub-error | This field MUST contain the value of the Error |
| Code Vendor | Code Vendor ID field of a PA-TNC Error attribute |
| ID | that describes the error condition encountered |
| | during subscription processing. |
| | |
| Sub-error | This field MUST contain the value of the Error |
| Code | Code field of a PA-TNC Error attribute that |
| | describes the error condition encountered during |
| | subscription processing. |
| | |
| Sub-error | This field MUST contain the value of the Error |
| Information | Information field of a PA-TNC Error attribute that |
| | describes the error condition encountered during |
| | subscription processing. |
+--------------+----------------------------------------------------+
Table 12: SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR Information Fields
表12：SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR情報フィールド
This error structure is used with the SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR status code. The first 4 octets of this error structure contain the Subscription ID of the subscription that was being fulfilled when the error occurred. The remaining fields of this error structure duplicate the fields of a PA-TNC Error attribute, referred to as the "sub-error". The error code of the sub-error corresponds to the code of the error that the SWIMA-PC encountered while fulfilling the given subscription. The sub-error MUST NOT have an error code of SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR.
このエラー構造は、SWIMA_SUBSCRIPTION_FULFILLMENT_ERRORステータスコードで使用されます。このエラー構造の最初の4オクテットには、エラーが発生したときに実行されていたサブスクリプションのサブスクリプションIDが含まれています。このエラー構造の残りのフィールドは、「サブエラー」と呼ばれるPA-TNCエラー属性のフィールドを複製します。サブエラーのエラーコードは、指定されたサブスクリプションの実行中にSWIMA-PCで発生したエラーのコードに対応します。サブエラーには、SWIMA_SUBSCRIPTION_FULFILLMENT_ERRORのエラーコードを含めることはできません。
The SWIMA-PC sending a PA-TNC Error attribute with this error code, and the SWIMA-PV receiving it, MUST treat the subscription identified by the Subscription ID field as cancelled. All other subscriptions are unaffected.
このエラーコードとともにPA-TNCエラー属性を送信するSWIMA-PC、およびそれを受信するSWIMA-PVは、サブスクリプションIDフィールドで識別されるサブスクリプションをキャンセル済みとして処理する必要があります。他のすべてのサブスクリプションは影響を受けません。
SWIMA supports an extensible list of data models for representing and transmitting software inventory information. This list of data models appears in the "Software Data Model Types" registry (see Section 10.5). This document provides guidance for an initial set of data models. Other documents might provide guidance on the use of new data models by SWIMA and will be referenced by extensions to the "Software Data Model Types" registry.
SWIMAは、ソフトウェアインベントリ情報を表現および送信するためのデータモデルの拡張可能なリストをサポートしています。このデータモデルのリストは、「ソフトウェアデータモデルタイプ」レジストリに表示されます（セクション10.5を参照）。このドキュメントは、データモデルの初期セットのガイダンスを提供します。その他のドキュメントは、SWIMAによる新しいデータモデルの使用に関するガイダンスを提供する場合があり、「ソフトウェアデータモデルタイプ」レジストリの拡張機能によって参照されます。
The International Organization for Standardization and the International Electrotechnical Commission (ISO/IEC) published the specification governing SWID tag construction and use (ISO/IEC 19770-2:2009) in 2009 [SWID09], with a revised version of the specification (ISO/IEC 19770-2:2015) published in 2015 [SWID15]. Since that time, a growing number of vendors have integrated SWID tags into their software products. SWID tags significantly simplify the task of identifying pieces of software: instead of relying on discovery processes that look for clues as to software presence, such as the presence of particular files or registry keys, vendors can use a readily available list of SWID tags that provides simple and immediate evidence as to the presence of the given piece of software.
国際標準化機構および国際電気標準会議（ISO / IEC）は、SWIDタグの構成と使用に関する規定（ISO / IEC 19770-2：2009）を2009年[SWID09]に改訂版の仕様（ISO / IEC / IEC 19770-2：2015）2015年に発行[SWID15]。それ以来、ソフトウェア製品にSWIDタグを統合するベンダーが増えています。 SWIDタグは、ソフトウェアの特定のタスクを大幅に簡素化します。ベンダーは、特定のファイルやレジストリキーの存在など、ソフトウェアの存在に関する手掛かりを探す発見プロセスに依存する代わりに、提供するSWIDタグのすぐに利用可能なリストを使用できます。与えられたソフトウェアの存在に関する単純で即時の証拠。
SWIMA has no reliance on the presence or management of SWID tags on an endpoint as described in the ISO 2015 SWID tag specification. However, as presented in the ISO 2015 SWID tag specification, the data model for describing software provides a robust and comprehensive way of describing software and is adopted here as a means of representing and transmitting software information. It should be emphasized that the use of the ISO SWID tag data model makes no assumption as to whether (1) the source of the recorded information was, in fact, an ISO SWID tag harvested from the endpoint or (2) the information was created using some other source and normalized to the SWID format.
ISO 2015 SWIDタグの仕様に記載されているように、SWIMAはエンドポイント上のSWIDタグの存在や管理に依存しません。ただし、ISO 2015 SWIDタグ仕様に示されているように、ソフトウェアを記述するためのデータモデルは、ソフトウェアを記述するための堅牢で包括的な方法を提供し、ソフトウェア情報を表現および送信する手段としてここで採用されます。 ISO SWIDタグデータモデルの使用は、（1）記録された情報のソースが実際にエンドポイントから取得されたISO SWIDタグであったか、または（2）情報が作成されたものであるかを想定していないことを強調する必要があります。他のソースを使用し、SWID形式に正規化します。
6.1.1. Guidance on Normalizing Source Data to ISO 2015 SWID Tags Using XML
6.1.1. XMLを使用してソースデータをISO 2015 SWIDタグに正規化するためのガイダンス
Any record associated with this Software Data Model Type MUST conform to [SWID15].
このソフトウェアデータモデルタイプに関連付けられたレコードは、[SWID15]に準拠する必要があります。
If generating a new ISO 2015 SWID tag, the software generating the tag MUST use a Tag Creator RegID that is associated with the generating software, unless this is impossible, in which case it MUST use the "http://invalid.unavailable" Tag Creator RegID value. (This conforms to conventions for an unknown tag creator in the ISO 2015 SWID tag specification.) Do not use a RegID associated with any other party. In particular, it is incorrect to use a Tag Creator RegID associated with the software being described by the tag, the enterprise that is using the software, or any other entity except that of the party that built the tool that is generating the SWID tag. This reflects the requirement that the Tag Creator RegID identify the party that created the tag. Moreover, any generated tags SHOULD conform to guidance for tag creators as provided in NISTIR 8060 [NIST8060], which provides additional recommendations to increase interoperable use of SWID tags.
新しいISO 2015 SWIDタグを生成する場合、タグを生成するソフトウェアは、生成可能なソフトウェアに関連付けられているTag Creator RegIDを使用する必要があります。これが不可能な場合を除き、 "http：//invalid.unavailable"タグを使用する必要があります。作成者のRegID値。 （これは、ISO 2015 SWIDタグ仕様の不明なタグ作成者の規則に準拠しています。）他のパーティに関連付けられているRegIDを使用しないでください。特に、タグで記述されているソフトウェア、ソフトウェアを使用している企業、またはSWIDタグを生成しているツールを構築した当事者以外のエンティティに関連付けられているタグ作成者RegIDを使用することは正しくありません。これは、Tag Creator RegIDがタグを作成した当事者を識別するという要件を反映しています。さらに、生成されたタグはすべて、NISTIR 8060 [NIST8060]で提供されるタグ作成者向けのガイダンスに準拠する必要があります。これは、SWIDタグの相互運用可能な使用を増やすための追加の推奨事項を提供します。
6.1.2. Guidance on Creation of Software Identifiers from ISO 2015 SWID Tags
6.1.2. ISO 2015 SWIDタグからのソフトウェア識別子の作成に関するガイダンス
A Software Identifier generated from an ISO 2015 SWID tag is expressed as a concatenation of the value of the Tag Creator RegID field and the Unique ID field. Specifically, (1) it MUST be of the form TAG_CREATOR_REGID "_" "_" UNIQUE_ID and (2) it consists of the Tag Creator RegID and the Unique ID from the tag connected with a double underscore (_), without any other connecting character or whitespace.
ISO 2015 SWIDタグから生成されたソフトウェア識別子は、タグ作成者のRegIDフィールドと一意のIDフィールドの値の連結として表されます。具体的には、（1）TAG_CREATOR_REGID "_" "_" UNIQUE_IDの形式である必要があります。（2）タグ作成者のRegIDと、二重下線（_）で接続されたタグの一意のIDで構成され、他の接続はありません。文字または空白。
As noted above, ISO's SWID tag specification provides a useful data model for representation of software information. As of the writing of this specification, while the ISO 2015 specification is considered more comprehensive and addresses some issues with the ISO 2009 specification, 2009-format SWID tags remain far more common in deployments. For this reason, ISO 2009 SWID tags are included in the "Software Data Model Types" registry.
上記のように、ISOのSWIDタグ仕様は、ソフトウェア情報の表現に役立つデータモデルを提供します。この仕様の執筆時点では、ISO 2015仕様はより包括的であると考えられており、ISO 2009仕様のいくつかの問題に対処していますが、2009形式のSWIDタグは、展開においてはるかに一般的です。このため、ISO 2009 SWIDタグは「ソフトウェアデータモデルタイプ」レジストリに含まれています。
6.2.1. Guidance on Normalizing Source Data to ISO 2009 SWID Tags Using XML
6.2.1. XMLを使用してソースデータをISO 2009 SWIDタグに正規化するためのガイダンス
Any record associated with this Software Data Model Type MUST conform to [SWID09]. Any such tag SHOULD use a UTF-8 encoding [RFC3629] but MUST NOT alter the existing encoding if doing so would invalidate digital signatures included in the tag.
このソフトウェアデータモデルタイプに関連付けられたレコードは、[SWID09]に準拠する必要があります。そのようなタグはUTF-8エンコーディング[RFC3629]を使用する必要があります[SHOULD]。ただし、既存のエンコーディングを変更すると、タグに含まれるデジタル署名が無効になる場合があります。
If generating a new ISO 2009 SWID tag, the software generating the tag MUST use a Tag Creator RegID that is associated with the generating software, unless this is impossible, in which case it MUST use "unknown", which indicates that the tag creator is unknown. (This conforms to conventions for an unknown tag creator in the ISO 2009 SWID tag specification.) Do not use a RegID associated with any other party. In particular, it is incorrect to use a Tag Creator RegID associated with the software being described by the tag, the enterprise that is using the software, or any other entity except that of the party that built the tool that is generating the SWID tag. This reflects the requirement that the Tag Creator RegID identify the party that created the tag.
新しいISO 2009 SWIDタグを生成する場合、タグを生成するソフトウェアは、生成ソフトウェアに関連付けられているタグ作成者RegIDを使用する必要があります。これが不可能な場合を除き、「不明」を使用する必要があります。これは、タグ作成者がわからない。 （これは、ISO 2009 SWIDタグ仕様の不明なタグ作成者の規則に準拠しています。）他のパーティに関連付けられているRegIDを使用しないでください。特に、タグで記述されているソフトウェア、ソフトウェアを使用している企業、またはSWIDタグを生成しているツールを構築した当事者以外のエンティティに関連付けられているタグ作成者RegIDを使用することは正しくありません。これは、Tag Creator RegIDがタグを作成した当事者を識別するという要件を反映しています。
6.2.2. Guidance on Creation of Software Identifiers from ISO 2009 SWID Tags
6.2.2. ISO 2009 SWIDタグからのソフトウェア識別子の作成に関するガイダンス
A Software Identifier generated from an ISO 2009 SWID tag is expressed as a concatenation of the value of the Tag Creator RegID field and the Unique ID field. Specifically, (1) it MUST be of the form TAG_CREATOR_REGID "_" "_" UNIQUE_ID and (2) it consists of the Tag Creator RegID and the Unique ID from the tag connected with a double underscore (_), without any other connecting character or whitespace.
ISO 2009 SWIDタグから生成されたソフトウェア識別子は、タグ作成者のRegIDフィールドと一意のIDフィールドの値の連結として表されます。具体的には、（1）TAG_CREATOR_REGID "_" "_" UNIQUE_IDの形式である必要があります。（2）タグ作成者のRegIDと、二重下線（_）で接続されたタグの一意のIDで構成され、他の接続はありません。文字または空白。
This specification is expected to participate in a standard NEA architecture. As such, it is expected to be used in conjunction with the other protocols used in a NEA exchange. In particular, SWIMA attributes are conveyed over PB-TNC [RFC5793], which is in turn conveyed over some variant of PT (either PT-TLS [RFC6876] or PT-EAP [RFC7171]). These protocols have an especially important role, as they are responsible for ensuring that attributes defined under this specification are delivered reliably, securely, and to the appropriate party.
この仕様は、標準のNEAアーキテクチャに参加することが期待されています。そのため、NEA交換で使用される他のプロトコルと組み合わせて使用されることが期待されています。特に、SWIMA属性はPB-TNC [RFC5793]を介して伝達されます。これは、PTのバリアント（PT-TLS [RFC6876]またはPT-EAP [RFC7171]のいずれか）を介して伝達されます。これらのプロトコルは、この仕様に基づいて定義された属性が確実に、安全に、適切な関係者に配信されるようにする責任があるため、特に重要な役割を果たします。
It is important to note that the Product Information, Numeric Version, and String Version attributes defined in the PA-TNC specification [RFC5792] are also meant to convey information about installed applications and the versions thereof. As such, there is some conceptual overlap between those attributes and the intent of this specification. However, PA-TNC was designed to respond to very specific queries about specific classes of products, while SWIMA is able to convey a broader query, resulting in a more comprehensive set of information regarding an endpoint's installed software. As such, this specification provides important capabilities not present in the PA-TNC specification.
PA-TNC仕様[RFC5792]で定義されている製品情報、数値バージョン、文字列バージョン属性は、インストールされているアプリケーションとそのバージョンに関する情報を伝えることも目的としていることに注意することが重要です。そのため、これらの属性とこの仕様の意図との間には、いくつかの概念的な重複があります。ただし、PA-TNCは、特定のクラスの製品に関する非常に具体的なクエリに応答するように設計されていますが、SWIMAはより広範なクエリを伝達できるため、エンドポイントにインストールされているソフトウェアに関するより包括的な情報が得られます。そのため、この仕様は、PA-TNC仕様にはない重要な機能を提供します。
The NEA architecture is intended to support a broad range of activities and, as such, might be employed by other specifications. For example, requirement T-001 in the SACM Requirements document [RFC8248] notes that NEA can support data collection from endpoints within the broader SACM architecture. (Other parts of the NEA architecture, which SWIMA uses, meet the other SACM data transport requirements.) In the SACM architecture, a SWIMA-PV corresponds to a "SACM Collector" and a SWIMA-PC corresponds to a "SACM Internal Collector". In the SACM architecture, SWIMA can support activities relating to software inventory collection. Specifically, SWIMA supports the SACM "Endpoint Posture Attribute Value Collection" use case (Section 2.1.3 in [RFC7632]) by describing a collection mechanism that enables event-driven, scheduled, and ad hoc data collection of software inventory information. SWIMA's flexibility with regard to the format of inventory data records means that it is compatible with virtually any data format that implements SACM's "Define, Publish, Query, and Retrieve Security Automation Data" use case (Section 2.1.1 in [RFC7632]). This is just one example of how SWIMA can support broader security solution standards. Note that while SWIMA can support these SACM use cases, SWIMA has no dependencies on the SACM architecture or any other context in which NEA might reasonably be applied.
NEAアーキテクチャは、幅広いアクティビティをサポートすることを目的としているため、他の仕様で採用されている場合があります。たとえば、SACM要件ドキュメント[RFC8248]の要件T-001は、NEAがより広範なSACMアーキテクチャ内のエンドポイントからのデータ収集をサポートできることを示しています。 （SWIMAが使用するNEAアーキテクチャーの他の部分は、他のSACMデータ転送要件を満たします。）SACMアーキテクチャーでは、SWIMA-PVは「SACMコレクター」に対応し、SWIMA-PCは「SACM内部コレクター」に対応します。 。 SACMアーキテクチャでは、SWIMAはソフトウェアインベントリ収集に関連するアクティビティをサポートできます。具体的には、SWIMAは、ソフトウェアインベントリ情報のイベント駆動型、スケジュール型、およびアドホックデータ収集を可能にする収集メカニズムを記述することにより、SACMの「エンドポイントポスチャ属性値の収集」ユースケース（[RFC7632]のセクション2.1.3）をサポートします。在庫データレコードの形式に関するSWIMAの柔軟性は、SACMの「セキュリティオートメーションデータの定義、公開、クエリ、および取得」ユースケースを実装する実質的にすべてのデータ形式と互換性があることを意味します（[RFC7632]のセクション2.1.1）。これは、SWIMAがより広範なセキュリティソリューション標準をサポートする方法の一例にすぎません。 SWIMAはこれらのSACMユースケースをサポートできますが、SWIMAはSACMアーキテクチャまたはNEAが合理的に適用される可能性があるその他のコンテキストに依存しないことに注意してください。
This section discusses some of the security threats facing SWIMA-PCs and SWIMA-PVs. This section primarily notes potential issues for implementers to consider, although it does contain a handful of normative requirements to address certain security issues. The issues identified below focus on capabilities specific to this document. Implementers are advised to consult other relevant NEA specifications, particularly [RFC5209] (the NEA architecture) and [RFC5792] (PA-TNC), for security issues that are applicable to such components in general.
このセクションでは、SWIMA-PCおよびSWIMA-PVが直面しているセキュリティの脅威について説明します。このセクションでは、特定のセキュリティ問題に対処するための規範的な要件がいくつか含まれていますが、主に実装者が考慮すべき潜在的な問題について説明します。以下に示す問題は、このドキュメントに固有の機能に焦点を当てています。実装者は、このようなコンポーネントに一般的に適用されるセキュリティ問題について、他の関連するNEA仕様、特に[RFC5209]（NEAアーキテクチャ）および[RFC5792]（PA-TNC）を参照することをお勧めします。
The degree to which an endpoint's Software Inventory Evidence Collection accurately reflects the endpoint's actual software load and any changes made to this software load is dependent on the accuracy of the tools used to populate and manage the Software Inventory Evidence Records in this collection. While the SWIMA-PC is required to detect changes to an endpoint's Software Inventory Evidence Collection in near real time, some tools might not be designed to update records in the Software Inventory Evidence Collection in real time. This can result in a collection that is out of sync with actual system state. Moreover, tools might inaccurately characterize software or fail to properly record its removal. Finally, it is likely that there will be software on the endpoint that is not tracked by any source and thus is not reflected in the Software Inventory Evidence Collection. Tools that implement SWIMA ought to be aware of these potential issues and minimize them, but completely eliminating such issues is likely impossible. Users of collected Software Inventory Evidence Records need to understand that the information provided by SWIMA cannot be treated as completely accurate. Nonetheless, having endpoints report this information can still provide useful insights into the state of the endpoint's software load and can alert administrators and policy tools of situations that require remediation.
エンドポイントのソフトウェアインベントリエビデンスコレクションがエンドポイントの実際のソフトウェア負荷を正確に反映する度合いと、このソフトウェアロードに加えられた変更は、このコレクションのソフトウェアインベントリエビデンスレコードの入力と管理に使用されるツールの精度に依存します。エンドポイントのソフトウェアインベントリエビデンスコレクションへの変更をほぼリアルタイムで検出するにはSWIMA-PCが必要ですが、ソフトウェアインベントリエビデンスコレクションのレコードをリアルタイムで更新するように設計されていないツールもあります。これにより、コレクションが実際のシステム状態と同期しなくなる可能性があります。さらに、ツールはソフトウェアの特性を不正確にしたり、ソフトウェアの削除を適切に記録できない場合があります。最後に、ソースによって追跡されないソフトウェアがエンドポイントに存在する可能性があり、ソフトウェアインベントリエビデンスコレクションに反映されません。 SWIMAを実装するツールは、これらの潜在的な問題を認識して最小化する必要がありますが、そのような問題を完全に排除することはおそらく不可能です。収集されたソフトウェアインベントリエビデンスレコードのユーザーは、SWIMAによって提供される情報を完全に正確なものとして扱うことができないことを理解する必要があります。それでも、エンドポイントにこの情報を報告させると、エンドポイントのソフトウェア負荷の状態に関する有用な洞察が得られ、修正が必要な状況について管理者やポリシーツールに警告することができます。
Collected software records can be sensitive in nature. This can include both security sensitivities and privacy sensitivities. Privacy sensitivities are discussed more in Section 9. With regard to security, inventory records represent a wealth of information about the endpoint in question, and for an adversary who does not already have access to the endpoint a collection of the endpoint's inventory records might provide many details that are useful for mounting an attack. A list of the inventory records associated with an endpoint reveals a list of software installed on the endpoint. This list can be very detailed, noting specific versions and even patch levels; an adversary can use this information to identify vulnerable software and design efficacious attacks.
収集されたソフトウェアレコードは、本質的に機密である可能性があります。これには、セキュリティの機密性とプライバシーの機密性の両方を含めることができます。プライバシーの機密性については、セクション9で詳しく説明します。セキュリティに関しては、インベントリレコードは問題のエンドポイントに関する豊富な情報を表し、エンドポイントへのアクセス権をまだ持っていない敵対者には、エンドポイントのインベントリレコードのコレクションが多くの情報を提供する可能性があります。攻撃を仕掛けるために役立つ詳細。エンドポイントに関連付けられているインベントリレコードのリストから、エンドポイントにインストールされているソフトウェアのリストがわかります。このリストは非常に詳細になり、特定のバージョンやパッチレベルさえ記されています。攻撃者はこの情報を使用して、脆弱なソフトウェアを特定し、効果的な攻撃を設計できます。
The following information might also be gleaned from a collection of software inventory records:
次の情報も、ソフトウェアインベントリレコードのコレクションから収集される場合があります。
o An inventory record might include information about where the product was installed on a given endpoint. This can reveal details about the file organization of that endpoint that an attacker can utilize.
o インベントリレコードには、特定のエンドポイントで製品がインストールされた場所に関する情報が含まれる場合があります。これにより、攻撃者が利用できるそのエンドポイントのファイル編成に関する詳細が明らかになる可能性があります。
o An inventory record might include information about how the software was provided to the endpoint, who in an organization signs off on the package release, and who packaged the product for installation. This information might be used as a starting point for the development of supply chain attacks.
o インベントリレコードには、ソフトウェアがエンドポイントにどのように提供されたか、組織内のだれがパッケージリリースを承認したか、およびインストール用に製品をパッケージ化した人に関する情報が含まれる場合があります。この情報は、サプライチェーン攻撃の開発の出発点として使用される可能性があります。
o Events affecting inventory records are reported with timestamps indicating when each given event occurred. This can give the attacker an indication of how quickly an organization distributes patches and updates, helping the attacker determine how long an attack window might remain open.
o インベントリレコードに影響を与えるイベントは、特定の各イベントがいつ発生したかを示すタイムスタンプとともに報告されます。これにより、攻撃者は組織がパッチとアップデートを配布する速さを示すことができ、攻撃者が攻撃ウィンドウを開いたままにしておく期間を決定するのに役立ちます。
Any consolidated software inventory is a potential risk, because such an inventory can provide an adversary an insight into the enterprise's configuration and management process. It is recommended that a centralized software inventory record collection be protected against unauthorized access. Mechanisms to accomplish this can include encrypting the data at rest, ensuring that access to the data is limited only to authorized individuals and processes, and other basic security precautions.
統合されたソフトウェアインベントリは、企業の構成および管理プロセスに対する洞察を敵対者に提供する可能性があるため、潜在的なリスクです。集中管理されたソフトウェアインベントリレコードコレクションを不正アクセスから保護することをお勧めします。これを実現するメカニズムには、保管中のデータの暗号化、データへのアクセスが許可された個人とプロセスのみに制限されることの保証、その他の基本的なセキュリティ対策が含まれます。
SWIMA-PCs maintain records of detected changes to the endpoint's Software Inventory Evidence Collection. These records are used to respond to a SWIMA-PV's request for change events. The SWIMA-PV might use a list of reported events to update its understanding of the endpoint's Software Inventory Evidence Collection without needing to receive a full inventory report from the SWIMA-PC. For this reason, preserving the integrity of the SWIMA-PC's record of events is extremely important. If an attacker modifies the SWIMA-PC's record of changes to the endpoint's Software Inventory Evidence Collection, this might cause the SWIMA-PV's understanding of the endpoint's Software Inventory Evidence Collection to differ from its actual state. The results of such an attack might include leading the SWIMA-PV to believe that (1) absent software was present or, conversely, that present software was absent or (2) patches have been installed even if this is not the case. Such an attack could also cause the SWIMA-PV to be unaware of other changes to Software Inventory Evidence Records. As such, the SWIMA-PC MUST take steps to protect the integrity of its event records.
SWIMA-PCは、エンドポイントのソフトウェアインベントリエビデンスコレクションに対して検出された変更の記録を維持します。これらのレコードは、変更イベントに対するSWIMA-PVの要求に応答するために使用されます。 SWIMA-PVは、報告されたイベントのリストを使用して、SWIMA-PCから完全なインベントリレポートを受信する必要なしに、エンドポイントのソフトウェアインベントリエビデンスコレクションの理解を更新します。このため、SWIMA-PCのイベント記録の整合性を維持することは非常に重要です。攻撃者がエンドポイントのソフトウェアインベントリエビデンスコレクションに対する変更のSWIMA-PCのレコードを変更すると、SWIMA-PVによるエンドポイントのソフトウェアインベントリエビデンスコレクションの理解が実際の状態と異なる可能性があります。そのような攻撃の結果として、SWIMA-PVに、（1）ソフトウェアが存在しない、または逆に、現在のソフトウェアが存在しない、または（2）パッチがインストールされていない場合でも、それがインストールされていると思わせることがあります。このような攻撃により、SWIMA-PVはソフトウェアインベントリエビデンスレコードへの他の変更を認識できなくなります。そのため、SWIMA-PCは、イベントレコードの整合性を保護するための措置を講じる必要があります。
In addition, records of established SWIMA-PV subscriptions also require protection against manipulation or corruption. If an attacker is able to modify or delete records of a SWIMA-PV's established subscription, the SWIMA-PC might fail to correctly fulfill this subscription. The SWIMA-PV would not be aware that its subscription was not being correctly fulfilled unless it received additional information that indicated a discrepancy. For example, the SWIMA-PV might collect a full inventory and realize from this information that certain events had not been correctly reported in accordance with an established subscription. For this reason, the SWIMA-PC MUST protect the integrity of subscription records.
さらに、確立されたSWIMA-PVサブスクリプションの記録には、操作または破損に対する保護も必要です。攻撃者がSWIMA-PVの確立されたサブスクリプションのレコードを変更または削除できる場合、SWIMA-PCはこのサブスクリプションを正しく実行できない可能性があります。 SWIMA-PVは、矛盾を示す追加情報を受信しない限り、サブスクリプションが正しく実行されなかったことを認識しません。たとえば、SWIMA-PVは完全なインベントリを収集し、確立されたサブスクリプションに従って特定のイベントが正しく報告されなかったことをこの情報から認識します。このため、SWIMA-PCはサブスクリプションレコードの整合性を保護する必要があります。
A SWIMA-PC requires sufficient permissions to collect Software Inventory Evidence Records from all of its supported sources, as well as sufficient permissions to interact with the endpoint's Posture Broker Client. With regard to the former, this might require permissions to read the contents of directories throughout the filesystem. Depending on the operating environment and other activities undertaken by a SWIMA-PC (or software that incorporates a SWIMA-PC as one of its capabilities), additional permissions might be required by the SWIMA-PC software. The SWIMA-PC SHOULD NOT be granted permissions beyond what it needs to fulfill its duties.
SWIMA-PCには、サポートされているすべてのソースからソフトウェアインベントリエビデンスレコードを収集するための十分な権限と、エンドポイントのポスチャブローカークライアントと対話するための十分な権限が必要です。前者に関しては、ファイルシステム全体のディレクトリの内容を読み取るための権限が必要になる場合があります。 SWIMA-PC（または機能の1つとしてSWIMA-PCを組み込んだソフトウェア）によって実行される動作環境やその他のアクティビティによっては、SWIMA-PCソフトウェアで追加の権限が必要になる場合があります。 SWIMA-PCには、職務を遂行するために必要な範囲を超える権限を付与しないでください。
Not all sources of software inventory evidence are necessarily tightly controlled. For example, consider a source that gathers .swid files from the endpoint's filesystem. Any party could create a new .swid file that could be collected and turned into a Software Inventory Evidence Record. As a result, it is important that the contents of source information not be automatically trusted. In particular, tools that read source information and the Software Inventory Evidence Records derived therefrom, including SWIMA-PCs, need to be careful to sanitize input to prevent buffer overflow attacks, encoding attacks, and other weaknesses that might be exploited by an adversary who can control the contents of a record.
ソフトウェアインベントリの証拠のすべてのソースが必ずしも厳密に制御されるわけではありません。たとえば、エンドポイントのファイルシステムから.swidファイルを収集するソースについて考えてみます。すべての関係者が、収集してソフトウェアインベントリエビデンスレコードに変換できる新しい.swidファイルを作成できます。その結果、ソース情報の内容が自動的に信頼されないことが重要です。特に、SWIMA-PCを含む、ソース情報とそこから導出されたソフトウェアインベントリエビデンスレコードを読み取るツールは、バッファオーバーフロー攻撃、エンコーディング攻撃、および攻撃者が悪用できるその他の弱点を防ぐために、入力を無害化するように注意する必要があります。レコードの内容を制御します。
In addition to the aforementioned considerations, the SWIMA protocol is subject to the same security threats as other PA-TNC transactions; see Section 5.2 of PA-TNC [RFC5792]. These include, but are not limited to, attribute theft, message fabrication, attribute modification, attribute replay, attribute insertion, and denial of service. Implementers are advised to consult the PA-TNC specification to better understand these security issues.
前述の考慮事項に加えて、SWIMAプロトコルは他のPA-TNCトランザクションと同じセキュリティ上の脅威の影響を受けます。 PA-TNC [RFC5792]のセクション5.2を参照してください。これらには、属性の盗難、メッセージの作成、属性の変更、属性の再生、属性の挿入、およびサービス拒否が含まれますが、これらに限定されません。実装者は、PA-TNC仕様を参照して、これらのセキュリティ問題をよりよく理解することをお勧めします。
As noted in Section 8.2, if an adversary can gain an understanding of the software installed on an endpoint, they can utilize this to launch attacks and maintain footholds on this endpoint. For this reason, the NEA Server needs to ensure that adequate safeguards are in place to prevent exposure of collected inventory records. For similar reasons, it is advisable that an endpoint only send records to a NEA Server that is authorized to receive this information and that can be trusted to safeguard this information after collection.
セクション8.2で説明したように、攻撃者がエンドポイントにインストールされているソフトウェアを理解できる場合、攻撃者はこれを利用して攻撃を開始し、このエンドポイントの足場を維持できます。このため、NEAサーバーは、収集されたインベントリレコードが公開されないように、適切な保護手段が講じられていることを確認する必要があります。同様の理由で、エンドポイントは、この情報の受信を許可され、収集後にこの情報を保護するために信頼できるNEAサーバーにのみレコードを送信することをお勧めします。
In addition, software inventory information can lead to insights about the endpoint's primary user if that user is able to install software. (Note that users might be "able" to install their own software even if they are not "allowed" to do so.) This is especially true on endpoints that support "apps", as individual apps can be closely tied to specific groups or activities. This could conceivably allow inferences about things such as a user's hobbies; the banks and other financial institutions that they use; and information about the user's race, sex, or sexual orientation.
さらに、ユーザーがソフトウェアをインストールできる場合、ソフトウェアインベントリ情報はエンドポイントのプライマリユーザーに関する洞察につながる可能性があります。 （ユーザーは、「許可」されていなくても、自分のソフトウェアを「インストール」できる可能性があることに注意してください。）これは、「アプリ」をサポートするエンドポイントで特に当てはまります。個々のアプリは特定のグループまたは活動。これにより、ユーザーの趣味などの推論が可能になると考えられます。使用する銀行およびその他の金融機関。ユーザーの人種、性別、または性的指向に関する情報。
Organizations that collect software inventory information from endpoints ought to make sure the endpoints' users are aware of this collection. In addition, organizations should be aware that a software inventory associated with an individual, such as the inventory of the individual's primary endpoint, could expose sensitive personal information. For this reason, privacy safeguards are necessary for collected inventory information. Such safeguards would require not only protection of the inventory's confidentiality but also appropriate access controls so that only those trained in relevant privacy requirements are able to view the data.
エンドポイントからソフトウェアインベントリ情報を収集する組織は、エンドポイントのユーザーがこの収集を認識していることを確認する必要があります。さらに、組織は、個人のプライマリエンドポイントのインベントリなど、個人に関連付けられたソフトウェアインベントリが機密の個人情報を公開する可能性があることを認識する必要があります。このため、収集されたインベントリ情報にはプライバシー保護手段が必要です。そのような保護策には、在庫の機密性の保護だけでなく、関連するプライバシー要件のトレーニングを受けた者だけがデータを表示できるように、適切なアクセス制御も必要になります。
This section extends multiple existing IANA registries. Specifically, it extends the "PA-TNC Attribute Types" and "PA-TNC Error Codes" registries defined in the PA-TNC specification [RFC5792] and the "PA Subtypes" registry defined in the PB-TNC specification [RFC5793] and extended in PA-TNC. This specification only adds values to these registries and does not alter how these registries work or are maintained. Consult the appropriate specifications for details on the operations and maintenance of these registries.
このセクションでは、複数の既存のIANAレジストリを拡張します。具体的には、PA-TNC仕様[RFC5792]で定義された「PA-TNC属性タイプ」および「PA-TNCエラーコード」レジストリと、PB-TNC仕様[RFC5793]で定義された拡張された「PAサブタイプ」レジストリを拡張します。 PA-TNCで。この仕様は、これらのレジストリに値を追加するだけであり、これらのレジストリの動作や維持方法を変更しません。これらのレジストリの操作とメンテナンスの詳細については、適切な仕様を参照してください。
This section also defines a new IANA registry for "Software Data Model Types". The structure and requirements for this registry are provided, as well as guidelines for reviewers adjudicating the addition of new entries to this registry.
このセクションでは、「ソフトウェアデータモデルタイプ」の新しいIANAレジストリも定義します。このレジストリの構造と要件、およびこのレジストリへの新しいエントリの追加を審査者が判断するためのガイドラインが提供されます。
For the "Software Data Model Types" registry defined by this specification, new values are added to the registry using the "Specification Required" process defined in RFC 8126 [RFC8126].
この仕様で定義されている「ソフトウェアデータモデルタイプ」レジストリの場合、RFC 8126 [RFC8126]で定義されている「仕様が必要です」プロセスを使用して、新しい値がレジストリに追加されます。
This section provides guidance to designated experts so that they may make decisions using a philosophy appropriate for this registry.
このセクションでは、指定された専門家がこのレジストリに適した哲学を使用して意思決定できるように、ガイダンスを提供します。
Designated experts should focus on the following requirements. All values in this IANA registry MUST be documented in a specification that is permanently and publicly available. Values MUST also be useful, not harmful to the Internet, and defined in a manner that is clear and likely to ensure interoperability.
指定された専門家は、次の要件に焦点を当てる必要があります。このIANAレジストリのすべての値は、永続的かつ公的に利用可能な仕様に文書化されている必要があります。値は、インターネットに有害ではなく、有用である必要があり、明確で相互運用性を保証する可能性が高い方法で定義する必要があります。
Designated experts should encourage vendors to avoid defining similar but incompatible values and instead agree on a single value allocated via IETF standards. However, it is beneficial to document existing practice.
指定された専門家は、ベンダーが同様であるが互換性のない値を定義することを避け、代わりにIETF標準を介して割り当てられた単一の値に同意することを推奨する必要があります。ただし、既存のプラクティスを文書化することは有益です。
There are several ways to ensure that a specification is permanently and publicly available. It may be published as an RFC. Alternatively, it may be published in another manner that makes it freely available to anyone. However, in this latter case, the vendor MUST supply a copy to IANA and authorize IANA to archive this copy and make it freely available to all, if at some point the document becomes no longer freely available to all through other channels.
仕様が永続的かつ一般に利用可能であることを保証する方法はいくつかあります。 RFCとして公開される場合があります。あるいは、誰でも自由に利用できる別の方法で公開することもできます。ただし、この後者の場合、ベンダーがIANAにコピーを提供し、IANAがこのコピーをアーカイブしてすべてのユーザーが自由に利用できるようにする必要があります。
Sections 10.2, 10.3, and 10.4 define a new PA Subtype, new PA-TNC Attribute Types, and new PA-TNC Error Codes, respectively. Section 10.5 provides guidance to IANA in creating and managing the new "Software Data Model Types" registry defined by this specification.
セクション10.2、10.3、および10.4では、それぞれ新しいPAサブタイプ、新しいPA-TNC属性タイプ、および新しいPA-TNCエラーコードを定義しています。セクション10.5は、この仕様で定義された新しい「ソフトウェアデータモデルタイプ」レジストリを作成および管理する際のIANAへのガイダンスを提供します。
The following is an extension to the list of PA Subtypes provided in Section 7.2 of [RFC5792] and defined in the "PA Subtypes" registry in Section 6.3 of [RFC5793]. See <https://www.iana.org/assignments/ pb-tnc-parameters/>.
以下は、[RFC5792]のセクション7.2で提供され、[RFC5793]のセクション6.3の「PAサブタイプ」レジストリで定義されているPAサブタイプのリストの拡張です。 <https://www.iana.org/assignments/ pb-tnc-parameters />を参照してください。
+-----+---------+------------------+------------------------+
| PEN | Integer | Name | Defining Specification |
+-----+---------+------------------+------------------------+
| 0 | 9 | SWIMA Attributes | RFC 8412 |
+-----+---------+------------------+------------------------+
Section 5.2 of this specification defines several new PA-TNC attributes. The following values have been added to the "PA-TNC Attribute Types" registry defined in the PA-TNC specification. Note that Table 1 in Section 5.2 lists these attributes in both hexadecimal and decimal format. The decimal values given in that table are identical to those provided here. Note also that Table 1 includes an entry for the PA-TNC Error attribute, but the IANA information associated with the PA-TNC Error attribute is already defined in the PA-TNC specification and is not reproduced here.
この仕様のセクション5.2では、いくつかの新しいPA-TNC属性を定義しています。 PA-TNC仕様で定義されている「PA-TNC Attribute Types」レジストリに次の値が追加されました。セクション5.2の表1に、これらの属性を16進形式と10進形式の両方でリストしていることに注意してください。その表に示されている10進数の値は、ここで提供されているものと同じです。表1にはPA-TNCエラー属性のエントリが含まれていますが、PA-TNCエラー属性に関連付けられているIANA情報はPA-TNC仕様ですでに定義されているため、ここでは再現しないことに注意してください。
+-----+---------+----------------------------+----------------------+
| PEN | Integer | Name | Defining |
| | | | Specification |
+-----+---------+----------------------------+----------------------+
| 0 | 13 | SWIMA Request | RFC 8412 |
| | | | |
| 0 | 14 | Software Identifier | RFC 8412 |
| | | Inventory | |
| | | | |
| 0 | 15 | Software Identifier Events | RFC 8412 |
| | | | |
| 0 | 16 | Software Inventory | RFC 8412 |
| | | | |
| 0 | 17 | Software Events | RFC 8412 |
| | | | |
| 0 | 18 | Subscription Status | RFC 8412 |
| | | Request | |
| | | | |
| 0 | 19 | Subscription Status | RFC 8412 |
| | | Response | |
| | | | |
| 0 | 20 | Source Metadata Request | RFC 8412 |
| | | | |
| 0 | 21 | Source Metadata Response | RFC 8412 |
+-----+---------+----------------------------+----------------------+
Section 5.15 of this specification defines several new PA-TNC Error Codes. The following values have been added to the "PA-TNC Error Codes" registry defined in the PA-TNC specification. Note that Table 9 in Section 5.15 lists these codes in both hexadecimal and decimal format. The decimal values given in that table are identical to those provided here.
この仕様のセクション5.15は、いくつかの新しいPA-TNCエラーコードを定義しています。 PA-TNC仕様で定義されている「PA-TNCエラーコード」レジストリに次の値が追加されました。セクション5.15の表9に、これらのコードを16進形式と10進形式の両方でリストしていることに注意してください。その表に示されている10進数の値は、ここで提供されているものと同じです。
+-----+---------+--------------------------------------+---------------+
| PEN | Integer | Name | Defining |
| | | | Specification |
+-----+---------+--------------------------------------+---------------+
| 0 | 4 | SWIMA_ERROR | RFC 8412 |
| | | | |
| 0 | 5 | SWIMA_SUBSCRIPTION_DENIED_ERROR | RFC 8412 |
| | | | |
| 0 | 6 | SWIMA_RESPONSE_TOO_LARGE_ERROR | RFC 8412 |
| | | | |
| 0 | 7 | SWIMA_SUBSCRIPTION_FULFILLMENT_ERROR | RFC 8412 |
| | | | |
| 0 | 8 | SWIMA_SUBSCRIPTION_ID_REUSE_ERROR | RFC 8412 |
+-----+---------+--------------------------------------+---------------+
For the "Software Data Model Types" registry (<https://www.iana.org/assignments/pa-tnc-parameters/ #software-data-model-types>, each entry should include a human-readable name, an SMI PEN, a decimal integer value between 0 and 2^8-1 (inclusive), and a reference to the specification where the use of this data model is defined. This referenced specification needs to provide both a description of the format used by the data model and the procedures by which Software Identifiers are derived from a record expressed using this data model. Note that a specification that just defines the data model structure and its use is generally not sufficient, as it would likely lack the procedures for constructing a Software Identifier. This is why the table below uses the SWIMA standard for ISO SWID tags as the reference for the use of ISO SWID tags and does not reference the ISO SWID tag specification.
「ソフトウェアデータモデルタイプ」レジストリ（<https://www.iana.org/assignments/pa-tnc-parameters/＃software-data-model-types>）の場合、各エントリには、人間が読める名前、 SMI PEN、0〜2 ^ 8-1（両端を含む）の間の10進整数値、およびこのデータモデルの使用が定義されている仕様への参照。この参照されている仕様では、データモデルと、このデータモデルを使用して表現されたレコードからソフトウェア識別子を導出する手順。データモデルの構造とその使用を定義するだけの仕様では、ソフトウェアを構築するための手順が不足している可能性が高いため、通常は不十分です。識別子。これが、下の表がISO SWIDタグの使用の参照としてISO SWIDタグのSWIMA標準を使用し、ISO SWIDタグ仕様を参照しない理由です。
The following entries for this registry are defined in this document. They are the initial entries in the "Software Data Model Types" registry. Additional entries to this registry are added following the "Specification Required" policy defined in [RFC8126], following the guidelines in Section 10.1.
このドキュメントでは、このレジストリの次のエントリが定義されています。これらは、「ソフトウェアデータモデルタイプ」レジストリの最初のエントリです。このレジストリへの追加のエントリは、セクション10.1のガイドラインに従って、[RFC8126]で定義されている "Specification Required"ポリシーに従って追加されます。
+-----+---------+-----------------------------+---------------------+
| PEN | Integer | Name | Defining |
| | | | Specification |
+-----+---------+-----------------------------+---------------------+
| 0 | 0 | ISO 2015 SWID tags using | RFC 8412 |
| | | XML | |
| | | | |
| 0 | 1 | ISO 2009 SWID tags using | RFC 8412 |
| | | XML | |
| | | | |
| 0 | 192-255 | Reserved for local | N/A |
| | | enterprise use | |
+-----+---------+-----------------------------+---------------------+
[NIST8060] Waltermire, D., Cheikes, B., Feldman, L., and G. Witte, "Guidelines for the Creation of Interoperable Software Identification (SWID) Tags", DOI 10.6028/NIST.IR.8060, April 2016, <https://nvlpubs.nist.gov/nistpubs/ir/2016/ NIST.IR.8060.pdf>.
[NIST8060] Waltermire、D.、Cheikes、B.、Feldman、L。、およびG. Witte、「相互運用可能なソフトウェア識別（SWID）タグの作成に関するガイドライン」、DOI 10.6028 / NIST.IR.8060、2016年4月、 <https://nvlpubs.nist.gov/nistpubs/ir/2016/ NIST.IR.8060.pdf>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/info/rfc3339>.
[RFC3339] Klyne、G。およびC. Newman、「インターネット上の日付と時刻：タイムスタンプ」、RFC 3339、DOI 10.17487 / RFC3339、2002年7月、<https://www.rfc-editor.org/info/rfc3339 >。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<https://www.rfc-editor.org/info/ rfc3629>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<https：/ /www.rfc-editor.org/info/rfc3986>。
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, <https://www.rfc-editor.org/info/rfc5198>.
[RFC5198] Klensin、J。およびM. Padlipsky、「Network InterchangeのUnicode形式」、RFC 5198、DOI 10.17487 / RFC5198、2008年3月、<https://www.rfc-editor.org/info/rfc5198>。
[RFC5792] Sangster, P. and K. Narayan, "PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)", RFC 5792, DOI 10.17487/RFC5792, March 2010, <https://www.rfc-editor.org/info/rfc5792>.
[RFC5792] Sangster、P。およびK. Narayan、「PA-TNC：A Posture Attribute（PA）Protocol Compatible with Trusted Network Connect（TNC）」、RFC 5792、DOI 10.17487 / RFC5792、2010年3月、<https：// www.rfc-editor.org/info/rfc5792>。
[RFC8089] Kerwin, M., "The "file" URI Scheme", RFC 8089, DOI 10.17487/RFC8089, February 2017, <https://www.rfc-editor.org/info/rfc8089>.
[RFC8089] Kerwin、M。、「The "file" URI Scheme」、RFC 8089、DOI 10.17487 / RFC8089、2017年2月、<https://www.rfc-editor.org/info/rfc8089>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[SWID09] The International Organization for Standardization/ International Electrotechnical Commission, "Information technology - Software asset management - Part 2: Software identification tag", ISO/IEC 19770-2:2009, November 2009, <https://www.iso.org/standard/53670.html>.
[SWID09]国際標準化機構/国際電気標準会議、「情報技術-ソフトウェア資産管理-パート2：ソフトウェア識別タグ」、ISO / IEC 19770-2：2009、2009年11月、<https：//www.iso。 org / standard / 53670.html>。
[SWID15] The International Organization for Standardization/ International Electrotechnical Commission, "Information technology - Software asset management - Part 2: Software identification tag", ISO/IEC 19770-2:2015, October 2015, <https://www.iso.org/standard/65666.html>.
[SWID15]国際標準化機構/国際電気標準会議、「情報技術-ソフトウェア資産管理-パート2：ソフトウェア識別タグ」、ISO / IEC 19770-2：2015、2015年10月、<https：//www.iso。 org / standard / 65666.html>。
[RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. Tardo, "Network Endpoint Assessment (NEA): Overview and Requirements", RFC 5209, DOI 10.17487/RFC5209, June 2008, <https://www.rfc-editor.org/info/rfc5209>.
[RFC5209] Sangster、P.、Khosravi、H.、Mani、M.、Narayan、K。、およびJ. Tardo、「Network Endpoint Assessment（NEA）：Overview and Requirements」、RFC 5209、DOI 10.17487 / RFC5209、June 2008、<https://www.rfc-editor.org/info/rfc5209>。
[RFC5793] Sahita, R., Hanna, S., Hurst, R., and K. Narayan, "PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC)", RFC 5793, DOI 10.17487/RFC5793, March 2010, <https://www.rfc-editor.org/info/rfc5793>.
[RFC5793] Sahita、R.、Hanna、S.、Hurst、R。、およびK. Narayan、「PB-TNC：A Posture Broker（PB）Protocol Compatible with Trusted Network Connect（TNC）」、RFC 5793、DOI 10.17487 / RFC5793、2010年3月、<https://www.rfc-editor.org/info/rfc5793>。
[RFC6876] Sangster, P., Cam-Winget, N., and J. Salowey, "A Posture Transport Protocol over TLS (PT-TLS)", RFC 6876, DOI 10.17487/RFC6876, February 2013, <https://www.rfc-editor.org/info/rfc6876>.
[RFC6876] Sangster、P.、Cam-Winget、N。、およびJ. Salowey、「A Posture Transport Protocol over TLS（PT-TLS）」、RFC 6876、DOI 10.17487 / RFC6876、2013年2月、<https：// www.rfc-editor.org/info/rfc6876>。
[RFC7171] Cam-Winget, N. and P. Sangster, "PT-EAP: Posture Transport (PT) Protocol for Extensible Authentication Protocol (EAP) Tunnel Methods", RFC 7171, DOI 10.17487/RFC7171, May 2014, <https://www.rfc-editor.org/info/rfc7171>.
[RFC7171] Cam-Winget、N。およびP. Sangster、「PT-EAP：Posture Transport（PT）Protocol for Extensible Authentication Protocol（EAP）Tunnel Methods」、RFC 7171、DOI 10.17487 / RFC7171、2014年5月、<https： //www.rfc-editor.org/info/rfc7171>。
[RFC7632] Waltermire, D. and D. Harrington, "Endpoint Security Posture Assessment: Enterprise Use Cases", RFC 7632, DOI 10.17487/RFC7632, September 2015, <https://www.rfc-editor.org/info/rfc7632>.
[RFC7632] Waltermire、D。およびD. Harrington、「Endpoint Security Posture Assessment：Enterprise Use Cases」、RFC 7632、DOI 10.17487 / RFC7632、2015年9月、<https://www.rfc-editor.org/info/rfc7632 >。
[RFC8248] Cam-Winget, N. and L. Lorenzin, "Security Automation and Continuous Monitoring (SACM) Requirements", RFC 8248, DOI 10.17487/RFC8248, September 2017, <https://www.rfc-editor.org/info/rfc8248>.
[RFC8248] Cam-Winget、N。およびL. Lorenzin、「Security Automation and Continuous Monitoring（SACM）Requirements」、RFC 8248、DOI 10.17487 / RFC8248、2017年9月、<https://www.rfc-editor.org/ info / rfc8248>。
Authors' Addresses
著者のアドレス
Charles Schmidt The MITRE Corporation 202 Burlington Road Bedford, MA 01730 United States of America
チャールズシュミットザマイターコーポレーション202バーリントンロードベッドフォード、MA 01730アメリカ合衆国
Email: cmschmidt@mitre.org
Daniel Haynes The MITRE Corporation 202 Burlington Road Bedford, MA 01730 United States of America
ダニエルヘインズザマイターコーポレーション202バーリントンロードベッドフォード、MA 01730アメリカ合衆国
Email: dhaynes@mitre.org
Chris Coffin The MITRE Corporation 202 Burlington Road Bedford, MA 01730 United States of America
クリスコフィンザマイターコーポレーション202 Burlington Road Bedford、MA 01730アメリカ合衆国
Email: ccoffin@mitre.org
David Waltermire National Institute of Standards and Technology 100 Bureau Drive Gaithersburg, Maryland United States of America
デビッドウォルターミア国立標準技術研究所100 Bureau Driveゲーサーズバーグ、メリーランド州アメリカ合衆国
Email: david.waltermire@nist.gov
Jessica Fitzgerald-McKay United States National Security Agency 9800 Savage Road Ft. Meade, Maryland United States of America
ジェシカフィッツジェラルドマッケイ米国国家安全保障局9800サベージロードフォートアメリカ合衆国、メリーランド州ミード
Email: jmfitz2@radium.ncsc.mil