Internet Engineering Task Force (IETF) R. Sahita
Request for Comments: 5793 Intel
Category: Standards Track S. Hanna
ISSN: 2070-1721 Juniper
R. Hurst
Microsoft
K. Narayan
Cisco Systems
March 2010
Internet Engineering Task Force (IETF) R. Sahita
Request for Comments: 5793 Intel
Category: Standards Track S. Hanna
ISSN: 2070-1721 Juniper
R. Hurst
Microsoft
K. Narayan
Cisco Systems
March 2010
PB-TNC: A Posture Broker (PB) Protocol Compatible with Trusted Network Connect (TNC)
PB-TNC：与可信网络连接（TNC）兼容的姿态代理（PB）协议
Abstract
摘要
This document specifies PB-TNC, a Posture Broker protocol identical to the Trusted Computing Group's IF-TNCCS 2.0 protocol. The document then evaluates PB-TNC against the requirements defined in the NEA Requirements specification.
本文档指定了PB-TNC，这是一种姿态代理协议，与可信计算组的IF-TNCCS 2.0协议相同。然后，该文件根据NEA要求规范中定义的要求评估PB-TNC。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5793.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5793.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Prerequisites ..............................................4
1.2. Message Diagram Conventions ................................4
1.3. Terminology ................................................4
1.4. Conventions Used in This Document ..........................4
2. PB-TNC Design Considerations ....................................5
2.1. Message Addressing .........................................5
2.2. Vendor IDs .................................................7
2.3. Efficiency .................................................7
3. PB-TNC Protocol Description .....................................7
3.1. Protocol Overview ..........................................7
3.2. PB-TNC State Machine .......................................8
3.3. Layering on PT ............................................11
3.4. Example of PB-TNC Encapsulation ...........................12
4. PB-TNC Protocol Specification ..................................13
4.1. PB-TNC Header .............................................13
4.2. PB-TNC Message ............................................16
4.3. IETF Standard PB-TNC Message Types ........................19
4.4. PB-Experimental ...........................................19
1. Introduction ....................................................4
1.1. Prerequisites ..............................................4
1.2. Message Diagram Conventions ................................4
1.3. Terminology ................................................4
1.4. Conventions Used in This Document ..........................4
2. PB-TNC Design Considerations ....................................5
2.1. Message Addressing .........................................5
2.2. Vendor IDs .................................................7
2.3. Efficiency .................................................7
3. PB-TNC Protocol Description .....................................7
3.1. Protocol Overview ..........................................7
3.2. PB-TNC State Machine .......................................8
3.3. Layering on PT ............................................11
3.4. Example of PB-TNC Encapsulation ...........................12
4. PB-TNC Protocol Specification ..................................13
4.1. PB-TNC Header .............................................13
4.2. PB-TNC Message ............................................16
4.3. IETF Standard PB-TNC Message Types ........................19
4.4. PB-Experimental ...........................................19
4.5. PB-PA .....................................................20
4.6. PB-Assessment-Result ......................................25
4.7. PB-Access-Recommendation ..................................26
4.8. PB-Remediation-Parameters .................................28
4.9. PB-Error ..................................................32
4.10. PB-Language-Preference ...................................37
4.11. PB-Reason-String .........................................38
5. Security Considerations ........................................41
5.1. Threat Model ..............................................41
5.2. Countermeasures ...........................................42
6. IANA Considerations ............................................43
6.1. Designated Expert Guidelines ..............................44
6.2. Registry for PB-TNC Message Types .........................45
6.3. Registry for PA Subtypes ..................................45
6.4. Registry for PB-TNC Remediation Parameters Types ..........46
6.5. Registry for PB-TNC Error Codes ...........................46
7. Acknowledgments ................................................47
8. References .....................................................47
8.1. Normative References ......................................47
8.2. Informative References ....................................48
Appendix A. Use Cases .............................................49
A.1. Initial Client-Triggered Assessment .......................49
A.2. Server-Initiated Assessment with Remediation ..............54
A.3. Client-Triggered Reassessment .............................63
Appendix B. Evaluation against NEA Requirements ...................70
B.1. Evaluation against Requirement C-1 ........................70
B.2. Evaluation against Requirement C-2 ........................70
B.3. Evaluation against Requirement C-3 ........................70
B.4. Evaluation against Requirement C-4 ........................71
B.5. Evaluation against Requirement C-5 ........................71
B.6. Evaluation against Requirement C-6 ........................71
B.7. Evaluation against Requirement C-7 ........................72
B.8. Evaluation against Requirement C-8 ........................72
B.9. Evaluation against Requirement C-9 ........................72
B.10. Evaluation against Requirement C-10 ......................73
B.11. Evaluation against Requirement C-11 ......................73
B.12. Evaluation against Requirement PB-1 ......................74
B.13. Evaluation against Requirement PB-2 ......................74
B.14. Evaluation against Requirement PB-3 ......................74
B.15. Evaluation against Requirement PB-4 ......................75
B.16. Evaluation against Requirement PB-5 ......................75
B.17. Evaluation against Requirement PB-6 ......................76
4.5. PB-PA .....................................................20
4.6. PB-Assessment-Result ......................................25
4.7. PB-Access-Recommendation ..................................26
4.8. PB-Remediation-Parameters .................................28
4.9. PB-Error ..................................................32
4.10. PB-Language-Preference ...................................37
4.11. PB-Reason-String .........................................38
5. Security Considerations ........................................41
5.1. Threat Model ..............................................41
5.2. Countermeasures ...........................................42
6. IANA Considerations ............................................43
6.1. Designated Expert Guidelines ..............................44
6.2. Registry for PB-TNC Message Types .........................45
6.3. Registry for PA Subtypes ..................................45
6.4. Registry for PB-TNC Remediation Parameters Types ..........46
6.5. Registry for PB-TNC Error Codes ...........................46
7. Acknowledgments ................................................47
8. References .....................................................47
8.1. Normative References ......................................47
8.2. Informative References ....................................48
Appendix A. Use Cases .............................................49
A.1. Initial Client-Triggered Assessment .......................49
A.2. Server-Initiated Assessment with Remediation ..............54
A.3. Client-Triggered Reassessment .............................63
Appendix B. Evaluation against NEA Requirements ...................70
B.1. Evaluation against Requirement C-1 ........................70
B.2. Evaluation against Requirement C-2 ........................70
B.3. Evaluation against Requirement C-3 ........................70
B.4. Evaluation against Requirement C-4 ........................71
B.5. Evaluation against Requirement C-5 ........................71
B.6. Evaluation against Requirement C-6 ........................71
B.7. Evaluation against Requirement C-7 ........................72
B.8. Evaluation against Requirement C-8 ........................72
B.9. Evaluation against Requirement C-9 ........................72
B.10. Evaluation against Requirement C-10 ......................73
B.11. Evaluation against Requirement C-11 ......................73
B.12. Evaluation against Requirement PB-1 ......................74
B.13. Evaluation against Requirement PB-2 ......................74
B.14. Evaluation against Requirement PB-3 ......................74
B.15. Evaluation against Requirement PB-4 ......................75
B.16. Evaluation against Requirement PB-5 ......................75
B.17. Evaluation against Requirement PB-6 ......................76
This document specifies PB-TNC, a Posture Broker (PB) protocol identical to the Trusted Computing Group's IF-TNCCS 2.0 protocol [7]. The document then evaluates PB-TNC against the requirements defined in the Network Endpoint Assessment (NEA) Requirements specification [8].
本文件规定了PB-TNC，一种姿态代理（PB）协议，与可信计算集团的IF-TNCCS 2.0协议相同[7]。然后，该文件根据网络端点评估（NEA）需求规范[8]中定义的需求评估PB-TNC。
This document does not define an architecture or reference model. Instead, it defines a protocol that works within the reference model described in the NEA Requirements specification [8]. The reader is assumed to be thoroughly familiar with that document. No familiarity with TCG specifications is assumed.
本文档未定义架构或参考模型。相反，它定义了在NEA需求规范[8]中描述的参考模型内工作的协议。假定读者完全熟悉该文件。假设不熟悉TCG规范。
This specification defines the syntax of PB-TNC messages using diagrams. Each diagram depicts the format and size of each field in bits. Implementations MUST send the bits in each diagram as they are shown, traversing the diagram from top to bottom and then from left to right within each line (which represents a 32-bit quantity). Multi-byte fields representing numeric values must be sent in network (big endian) byte order.
本规范使用图表定义PB-TNC消息的语法。每个图表以位为单位描述每个字段的格式和大小。实现必须按照所示发送每个图中的位，从上到下遍历图，然后在每行中从左到右遍历（表示32位的数量）。表示数值的多字节字段必须以网络（大端）字节顺序发送。
Descriptions of bit field (e.g., flag) values are described referring to the position of the bit within the field. These bit positions are numbered from the most significant bit through the least significant bit, so a 1-octet field with only bit 0 set has the value 0x80.
比特字段（例如，标志）值的描述参考比特在字段中的位置来描述。这些位位置从最高有效位到最低有效位进行编号，因此仅设置了位0的1-octet字段的值为0x80。
This document reuses the terminology defined in the NEA Requirements document. One new term is defined in this section.
本文件重复使用了NEA需求文件中定义的术语。本节定义了一个新术语。
Batch - A group of PB-TNC messages sent over a Posture Transport (PT) protocol at one time. Since the PB-TNC protocol needs to be able to work over a half-duplex PT protocol, PB-TNC messages are grouped into batches. The Posture Broker Client sends one batch to the Posture Broker Server, which responds with a batch.
批处理-一次通过姿态传输（PT）协议发送的一组PB-TNC消息。由于PB-TNC协议需要能够在半双工PT协议上工作，因此PB-TNC消息被分组成批。姿态代理客户端向姿态代理服务器发送一个批，姿态代理服务器用一个批进行响应。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释。
The primary purpose of the PB-TNC protocol is to carry Posture Attribute (PA) messages between Posture Collectors and Posture Validators. Also, PB-TNC must carry messages between the Posture Broker Client and the Posture Broker Server (known as PB-TNC messages) and manage the state of the assessment.
PB-TNC协议的主要目的是在姿态采集器和姿态验证器之间传输姿态属性（PA）消息。此外，PB-TNC必须在姿态代理客户端和姿态代理服务器之间传输消息（称为PB-TNC消息），并管理评估的状态。
The NEA Overview and Requirements document [8] describes in section 5.1.1.1 several ways that messages can be addressed and delivered to the proper Posture Collector(s) and Posture Validator(s). Of the techniques described in that section, PB-TNC supports dynamic identifiers and message types.
NEA概述和要求文件[8]在第5.1.1.1节中描述了信息寻址和发送至正确姿势收集器和姿势验证器的几种方式。在该部分描述的技术中，PB-TNC支持动态标识符和消息类型。
Message types are the simplest and most common way to handle message delivery. Each PA message sent via PB-TNC has an associated PA message type, composed of a PA Message Vendor ID and a PA subtype.
消息类型是处理消息传递的最简单和最常见的方法。通过PB-TNC发送的每个PA消息都有一个关联的PA消息类型，由PA消息供应商ID和PA子类型组成。
The PA-TNC specification [10] provides a list of IETF Standard PA Subtypes, which are used with a PA Message Vendor ID of 0. These include values such as Operating System and Anti-Virus, which are used for messages relating to operating system and anti-virus posture.
PA-TNC规范[10]提供了IETF标准PA子类型的列表，这些子类型与PA消息供应商ID 0一起使用。这些值包括操作系统和防病毒等值，用于与操作系统和防病毒姿态相关的消息。
Vendor-specific PA message types may be indicated by placing the defining vendor's Structure of Management Information (SMI) Private Enterprise Number into the PA Message Vendor ID field and a PA Subtype value assigned by that vendor in the PA Subtype field. This allows each vendor to define its own set of PA Subtype values without worrying about collisions with other vendors or with standard values.
特定于供应商的PA消息类型可通过将定义供应商的管理信息结构（SMI）私有企业编号放入PA消息供应商ID字段和该供应商在PA子类型字段中分配的PA子类型值来指示。这允许每个供应商定义自己的PA子类型值集，而无需担心与其他供应商或标准值的冲突。
The PA message type is somewhat analogous to a MIME type in that it indicates the type of the PA message. Posture Collectors and Posture Validators can use local APIs to indicate to the Posture Broker Client and Posture Broker Server which PA message types they are interested in receiving. For instance, a Posture Validator that evaluates anti-virus posture might indicate that it would like to receive PA messages with a PA Message Vendor ID of 0 and a PA Subtype that matches the IETF Standard PA Subtype for Anti-Virus. It might also indicate interest in some vendor-specific PA message types to get additional vendor-specific information on anti-virus posture.
PA消息类型在某种程度上类似于MIME类型，因为它指示PA消息的类型。姿态采集器和姿态验证器可以使用本地API向姿态代理客户端和姿态代理服务器指示它们感兴趣接收的PA消息类型。例如，评估防病毒姿态的姿态验证器可能表示它希望接收PA消息供应商ID为0且PA子类型与用于防病毒的IETF标准PA子类型匹配的PA消息。它还可能表示对某些特定于供应商的PA消息类型感兴趣，以获取有关防病毒姿态的其他特定于供应商的信息。
This type-based subscription model allows great flexibility in design and implementation. One Posture Validator may be responsible for evaluating several functions: anti-virus and host-based firewall, for instance. Posture Collectors do not need to know which Posture Validators are installed on the Posture Broker Server or what they handle. The Posture Collector simply sends PA messages with message types and the Posture Broker Server delivers them to the right Posture Validators.
这种基于类型的订阅模型在设计和实现方面具有极大的灵活性。一个姿态验证器可能负责评估几个功能：例如，防病毒和基于主机的防火墙。姿态收集器不需要知道姿态代理服务器上安装了哪些姿态验证器，也不需要知道它们处理什么。姿态收集器只发送带有消息类型的PA消息，姿态代理服务器将它们传递给正确的姿态验证器。
Because the Posture Broker Client and Posture Broker Server must have access to the PA Message Vendor ID and PA Subtype fields and because these are routing identifiers independent of the contents of the PA messages, these fields are located in PB-TNC not inside the PA messages themselves.
由于姿态代理客户端和姿态代理服务器必须能够访问PA消息供应商ID和PA子类型字段，并且这些字段是独立于PA消息内容的路由标识符，因此这些字段位于PB-TNC中，而不是PA消息本身内。
A similar type-based system is used to tag PB-TNC messages. In this case, the extensibility benefits are not as essential as with PA-TNC messages, but the ability to define IETF Standard PB-TNC Message Types and vendor-specific PB-TNC message types is still valuable.
类似的基于类型的系统用于标记PB-TNC消息。在这种情况下，可扩展性优势不像PA-TNC消息那样重要，但定义IETF标准PB-TNC消息类型和供应商特定PB-TNC消息类型的能力仍然很有价值。
The type-based message delivery model described above is not ideal for all circumstances. Sometimes it is important for a Posture Collector to deliver a message to a particular Posture Validator. For example, a particular Posture Validator might send a remediation message and the Posture Collector might need to send a response only to that one Posture Validator. To handle this circumstance, PB-TNC provides delivery based on dynamic identifiers.
上述基于类型的消息传递模型并非适用于所有情况。有时，姿势采集器将消息传递给特定的姿势验证器非常重要。例如，特定姿势验证器可能会发送修正消息，而姿势收集器可能只需要向该姿势验证器发送响应。为了处理这种情况，PB-TNC提供了基于动态标识符的交付。
When a Posture Broker Server loads a Posture Validator, it assigns it a Posture Validator ID. Any PA messages sent by a Posture Validator include that Posture Validator's Posture Validator ID in the Posture Validator ID field of the PB-PA message. A Posture Collector that receives such a message can send a message in response and request exclusive delivery to the Posture Validator identified by that Posture Validator ID.
当姿态代理服务器加载姿态验证器时，它会为其分配一个姿态验证器ID。任何由姿态验证器发送的PA消息都会在PB-PA消息的姿态验证器ID字段中包含该姿态验证器的姿态验证器ID。接收此类消息的姿势收集器可以发送消息作为响应，并请求以独占方式传递给由该姿势验证器ID标识的姿势验证器。
Dynamic identifiers avoid problems caused by the multicast nature of message types. Multiple Posture Collectors or Posture Validators may be registered for the same message type, and this can cause confusion if they all respond and the software designer did not consider that possibility. The dynamic identifier system allows more directed responses, but it does not work until at least one message has been received (so that the dynamic identifiers can be received). Static identifiers were considered as another alternative but rejected because they result in a brittle system that only works with a
动态标识符避免了由消息类型的多播性质引起的问题。多个姿势收集器或姿势验证器可以注册为相同的消息类型，这可能会导致混淆，如果他们都响应，软件设计师不考虑这种可能性。动态标识符系统允许更多定向响应，但在至少接收到一条消息（以便可以接收动态标识符）之前，它不会工作。静态标识符被认为是另一种选择，但被拒绝了，因为它们导致了一个只与
particular set of Posture Collectors and Posture Validators and causes problems if two Posture Collectors or Posture Validators with the same static identifier are installed.
一组特定的姿势采集器和姿势验证器，如果安装了两个具有相同静态标识符的姿势采集器或姿势验证器，则会导致问题。
In several places, PB-TNC needs to define a set of standard values but also allow vendor-specific extensions. In each of these places (PB-TNC Message Types, PA Subtypes, Remediation Parameters Types, and Error Codes), the solution chosen was to preface the values with a vendor ID. If a vendor ID is 0, the values in the next field are registered in an IANA registry and their meanings defined in an RFC. If a vendor ID is non-zero, the values in the next field are vendor specific and defined by the vendor whose SMI Private Enterprise Number matches the vendor ID. Vendor-specific messages that are not understood by the recipient are ignored and skipped unless they have the NOSKIP flag set, in which case an error code is returned.
在一些地方，PB-TNC需要定义一组标准值，但也允许特定于供应商的扩展。在每个位置（PB-TNC消息类型、PA子类型、修正参数类型和错误代码），选择的解决方案是在值之前加上供应商ID。如果供应商ID为0，则下一个字段中的值在IANA注册表中注册，其含义在RFC中定义。如果供应商ID为非零，则下一个字段中的值是特定于供应商的，由SMI私有企业编号与供应商ID匹配的供应商定义。收件人无法理解的特定于供应商的消息将被忽略和跳过，除非它们设置了NOSKIP标志，在这种情况下，将返回错误代码。
PB-TNC needs to work with low bandwidth transports and low power devices. Therefore, a simple, compact format was chosen for the PB-TNC protocol: binary messages with a Type-Length-Value structure.
PB-TNC需要使用低带宽传输和低功耗设备。因此，PB-TNC协议选择了一种简单、紧凑的格式：具有类型-长度-值结构的二进制消息。
The PB-TNC protocol carries batches of PB messages between a Posture Broker Client and a Posture Broker Server. It encapsulates PA messages and manages the NEA session. It runs over a PT protocol.
PB-TNC协议在姿态代理客户端和姿态代理服务器之间承载批量PB消息。它封装PA消息并管理NEA会话。它通过PT协议运行。
In order to work well over half-duplex PT protocols (such as those based on EAP [9]), PB-TNC supports half-duplex protocol operation. In this mode, the Posture Broker Client and Posture Broker Server take turns sending a single batch of messages to each other. While the half-duplex nature of PB-TNC could slow exchanges that require many round trips or bidirectional multimedia exchanges, this is not a problem in practice because endpoint assessments do not typically involve multimedia or a large number of round trips. The benefit of working over half-duplex transports outweighs any limitations imposed.
为了在半双工PT协议（例如基于EAP[9]）上正常工作，PB-TNC支持半双工协议操作。在此模式下，姿态代理客户端和姿态代理服务器轮流向彼此发送一批消息。虽然PB-TNC的半双工性质可能会减慢需要多次往返或双向多媒体交换的交换速度，但这在实践中不是问题，因为端点评估通常不涉及多媒体或大量往返。在半双工传输上工作的好处超过了强加的任何限制。
PB-TNC also supports full-duplex protocol operation so that PB-TNC exchanges can be re-initialized immediately when needed (e.g., if the Posture Broker Server policy changes or if the Posture Broker Client detects a suspicious event).
PB-TNC还支持全双工协议操作，以便PB-TNC交换可以在需要时立即重新初始化（例如，如果姿态代理服务器策略更改或姿态代理客户端检测到可疑事件）。
Each PB-TNC batch consists of a header followed by a sequence of PB-TNC messages. Each PB-TNC message has a Type-Length-Value (TLV) format with a few flags. The TLV format allows a recipient to skip messages that it does not understand. The TLV format also provides a standard way to mark messages as mandatory to ensure interoperability between a Posture Broker Client and a Posture Broker Server.
每个PB-TNC批由一个标头和一系列PB-TNC消息组成。每个PB-TNC消息都有一个带有几个标志的类型长度值（TLV）格式。TLV格式允许收件人跳过其不理解的邮件。TLV格式还提供了一种将消息标记为强制消息的标准方法，以确保姿态代理客户端和姿态代理服务器之间的互操作性。
This specification defines certain standard PB-TNC message types. It also permits vendors to define their own vendor-specific message types. One of the most important standard PB-TNC message types is PB-PA. A message with this type contains a PA message and various message routing information. A Posture Broker Client or Posture Broker Server that receives such a message does not interpret the PA message within. Instead, it delivers the PA message to the appropriate set of Posture Collectors or Posture Validators, as determined using the message routing information contained in the PB-PA message.
本规范定义了某些标准PB-TNC消息类型。它还允许供应商定义自己的特定于供应商的消息类型。PB-PA是最重要的标准PB-TNC消息类型之一。此类型的消息包含PA消息和各种消息路由信息。接收到此类消息的姿态代理客户端或姿态代理服务器不会解释其中的PA消息。相反，它将PA消息传递给一组适当的姿势收集器或姿势验证器，如使用PB-PA消息中包含的消息路由信息所确定的。
A Posture Broker Server will often need to communicate with several Posture Broker Clients at once. The reverse may also be true, as when an endpoint has multiple network interfaces connected to different networks. Each connection between a Posture Broker Server and a Posture Broker Client is instantiated as a separate PB-TNC session. There may be several simultaneous sessions between a single Posture Broker Server and Posture Broker Client, but this is unusual.
姿态代理服务器通常需要同时与多个姿态代理客户端通信。反之亦然，当一个端点有多个连接到不同网络的网络接口时。姿态代理服务器和姿态代理客户端之间的每个连接都被实例化为单独的PB-TNC会话。单个姿态代理服务器和姿态代理客户端之间可能同时有多个会话，但这是不寻常的。
Figure 1 illustrates the PB-TNC state machine, showing the set of states that a PB-TNC session can have and the possible transitions among these states. The following paragraphs describe this state machine in more detail.
图1说明了PB-TNC状态机，显示了PB-TNC会话可以具有的一组状态以及这些状态之间可能的转换。以下段落将更详细地描述此状态机。
Receive CRETRY SRETRY
or SRETRY +----------------+
+--+ | |
v | v |
+---------+ CRETRY +---------+
CDATA | Server |<---------| Decided | CLOSE
+----------->| Working |--------->| |-------+
| +---------+ RESULT +---------+ |
| ^ | | v
| | | +---------------------->=======
======== | | CLOSE " End "
" Init " CDATA| |SDATA =======
======== | | ^ ^
| | | v | |
| | SDATA +---------+ CLOSE | |
| +-------->| Client |----------------------+ |
| | Working | |
| +---------+ |
| | ^ |
| +--+ |
| Receive CRETRY |
| CLOSE |
+--------------------------------------------------+
Receive CRETRY SRETRY
or SRETRY +----------------+
+--+ | |
v | v |
+---------+ CRETRY +---------+
CDATA | Server |<---------| Decided | CLOSE
+----------->| Working |--------->| |-------+
| +---------+ RESULT +---------+ |
| ^ | | v
| | | +---------------------->=======
======== | | CLOSE " End "
" Init " CDATA| |SDATA =======
======== | | ^ ^
| | | v | |
| | SDATA +---------+ CLOSE | |
| +-------->| Client |----------------------+ |
| | Working | |
| +---------+ |
| | ^ |
| +--+ |
| Receive CRETRY |
| CLOSE |
+--------------------------------------------------+
Figure 1: PB-TNC state machine
图1:PB-TNC状态机
In this diagram, states are indicated by rectangular boxes. The initial and terminal states have double outlines (with = and "). State transitions are indicated by unidirectional arrows marked with the cause of the transition.
在此图中，状态由矩形框表示。初始和终端状态具有双轮廓（带=和“）。状态转换由标有转换原因的单向箭头指示。
Many transitions (CDATA, SDATA, CRETRY, SRETRY, and RESULT) are triggered by the transmission or reception of a PB-TNC batch of a particular type. The type of a PB-TNC batch is indicated by the contents of the Batch Type field in the PB-TNC header for that batch. For brevity, this document says "a FOO batch" instead of "a PB-TNC batch whose Batch Type field contains FOO". Other transitions are triggered by receiving a PB-TNC batch of a particular type (e.g., Receive CRETRY). The CLOSE transition may be triggered by sending or receiving a CLOSE batch but may also be triggered by termination of the underlying PT connection.
许多转换（CDATA、SDATA、CRETRY、SRETRY和RESULT）都是由特定类型的PB-TNC批的传输或接收触发的。PB-TNC批次的类型由该批次的PB-TNC标题中批次类型字段的内容指示。为简洁起见，本文档使用“一个FOO批处理”，而不是“其批处理类型字段包含FOO的PB-TNC批处理”。其他转换通过接收特定类型的PB-TNC批次（例如，接收CRETRY）触发。关闭转换可通过发送或接收关闭批次触发，但也可通过终止基础PT连接触发。
A PB-TNC session starts in the Init state when the underlying transport protocol (PT) establishes a connection between a Posture Broker Client and a Posture Broker Server. If the Posture Broker Client initiated the underlying transport session, it starts by sending a CDATA batch to the Posture Broker Server, thus causing a transition to the Server Working state. If the Posture Broker Server
当底层传输协议（PT）在姿态代理客户机和姿态代理服务器之间建立连接时，PB-TNC会话将以初始状态启动。如果姿态代理客户端启动了底层传输会话，它将首先向姿态代理服务器发送CDATA批，从而导致转换到服务器工作状态。如果代理服务器
initiated the transport session, it starts by sending a PB-TNC batch of type SDATA to the Posture Broker Client, thus causing a transition to the Client Working state.
在启动传输会话时，它首先将类型为SDATA的PB-TNC批发送到POSITION Broker客户端，从而导致转换到客户端工作状态。
The Posture Broker Client and Posture Broker Server may now alternate sending CDATA and SDATA batches to each other. Only the Posture Broker Client can send a data batch when the session is in the Client Working state, and only the Posture Broker Server can send a data batch when the session is in the Server Working state.
姿态代理客户端和姿态代理服务器现在可以交替向彼此发送CDATA和SDATA批。当会话处于客户端工作状态时，只有姿态代理客户端可以发送数据批，当会话处于服务器工作状态时，只有姿态代理服务器可以发送数据批。
The most common way to end an exchange is for the Posture Broker Server to send a RESULT batch. This causes a transition into the Decided state. This is not a terminal state. The PT session can remain open and another exchange can be initiated by having the Posture Broker Client send a CRETRY batch. This can be useful when the Posture Broker Client (or more likely a Posture Collector) discovers a suspicious condition on the endpoint, for example. If the underlying transport protocol (PT) supports full-duplex operation, the Posture Broker Server can also initiate another exchange from this state by sending a SRETRY batch. This can be useful when the policy changes on the server, for example.
结束交换的最常见方式是由姿态代理服务器发送结果批处理。这会导致转换到已决定的状态。这不是一个终端状态。PT会话可以保持打开状态，并且可以通过让姿态代理客户端发送CRETRY批来启动另一个交换。例如，当姿态代理客户端（或者更可能是姿态收集器）发现端点上的可疑情况时，这可能非常有用。如果基础传输协议（PT）支持全双工操作，则姿态代理服务器还可以通过发送SRETRY批处理从该状态启动另一个交换。例如，当服务器上的策略更改时，这可能很有用。
Whether an SRETRY or CRETRY message or both are sent, the next state is the Server Working State. From this state, the Posture Broker Server sends an SDATA batch and the new exchange begins. The state transitions marked Receive CRETRY and Receive CRETRY or SRETRY indicate that it is permissible to receive such messages in the indicated states, generally when the Posture Broker Client sent a CRETRY message at roughly the same time as the Posture Broker Server decided to send an SRETRY. In that case, a CRETRY message may be received while in the Server Working or Client Working state. Also, an SRETRY message may be received while in the Server Working state. These messages are redundant and therefore ignored, as indicated by the relevant transitions, which don't cause a state change.
无论发送的是SRETRY或CRETRY消息还是两者，下一个状态都是服务器工作状态。从该状态开始，姿态代理服务器发送一个SDATA批处理，新的交换开始。标记为Receive CRETRY和Receive CRETRY或SRETRY的状态转换表明，通常当姿态代理客户端在姿态代理服务器决定发送SRETRY的大致同时发送CRETRY消息时，可以在指示的状态下接收此类消息。在这种情况下，可能会在服务器工作或客户端工作状态下接收CRETRY消息。此外，在服务器工作状态下可能会收到SRETRY消息。这些消息是冗余的，因此被忽略，如相关转换所示，不会导致状态更改。
The only terminal state is the End state. This state is reached if the underlying PT connection closes. This can be caused by an action of the Posture Broker Client or Posture Broker Server or it can be caused by some external factor, such as pulling the network plug. When possible, a CLOSE batch SHOULD be sent before the underlying PT connection is terminated. However, there may be cases where the PT connection is closed without notice. For example, a plug may be pulled, a software program may fail, or a Posture Broker Client or Posture Broker Server may be unable to send a CLOSE message due to half-duplex limitations in the underlying PT protocol. In these cases, the Posture Broker Client and Posture Broker Server will generally receive some form of notification from the Posture Transport Client and Posture Transport Server that the PT connection
唯一的终端状态是结束状态。如果基础PT连接关闭，则达到此状态。这可能是由姿态代理客户端或姿态代理服务器的操作引起的，也可能是由某些外部因素引起的，例如拔掉网络插头。如果可能，应在基础PT连接终止之前发送关闭批处理。但是，在某些情况下，PT连接可能会在未通知的情况下关闭。例如，由于基础PT协议中的半双工限制，可能会拔出插头，软件程序可能会失败，或者姿态代理客户端或姿态代理服务器可能无法发送关闭消息。在这些情况下，姿态代理客户端和姿态代理服务器通常会收到来自姿态传输客户端和姿态传输服务器的某种形式的通知，通知PT连接
has been closed. This notification can trigger the CLOSE transition. However, the notification interaction is not standardized since the vertical interfaces in the NEA Reference Model are not standardized. In any case, the reception of the CLOSE batch or notification of termination of the transport causes the transition to the End state.
已经关闭了。此通知可触发关闭转换。然而，由于NEA参考模型中的垂直接口未标准化，因此通知交互未标准化。在任何情况下，接收到关闭批次或传输终止通知都会导致转换到结束状态。
Note that a Posture Broker Client and Posture Broker Server may not always have exactly the same state for a given PB-TNC session. For example, say that a session is in the Client Working state and the Posture Broker Client transmits a CDATA batch. While this batch is in transit (transmitted by the Posture Broker Client but not yet received by the Posture Broker Server), the Posture Broker Client will think that the session is in Server Working state but the Posture Broker Server will think that the session is in Client Working state. However, this is a temporary condition and does not cause problems in practice. The only possible issue is that a Posture Broker Client or Posture Broker Server does not know whether the other party has received its message until it receives a response from the other party.
请注意，对于给定的PB-TNC会话，姿态代理客户端和姿态代理服务器可能并不总是具有完全相同的状态。例如，假设会话处于客户机工作状态，姿态代理客户机传输CDATA批处理。当此批处理正在传输（由姿态代理客户端传输，但姿态代理服务器尚未接收）时，姿态代理客户端将认为会话处于服务器工作状态，但姿态代理服务器将认为会话处于客户端工作状态。然而，这只是一种暂时的情况，在实践中不会造成问题。唯一可能的问题是，在收到另一方的响应之前，姿态代理客户端或姿态代理服务器不知道另一方是否已收到其消息。
If a half-duplex transport is used, note that the Posture Broker Server cannot send a SRETRY batch when the session is in the Decided state because the Posture Broker Server sent the most recent batch (the RESULT batch) and this would violate the half-duplex nature of the transport protocol. Instead, a server that wishes to initiate a new exchange in the Decided state when a half-duplex transport is in use should close the PT connection without sending a CLOSE batch and start a new PB-TNC session. This limitation does not exist when a full-duplex transport is used.
如果使用半双工传输，请注意，当会话处于已决定状态时，姿态代理服务器无法发送SRETRY批，因为姿态代理服务器发送了最近的批（结果批），这将违反传输协议的半双工性质。相反，当使用半双工传输时，希望在确定状态下启动新交换的服务器应关闭PT连接，而不发送关闭批，并启动新的PB-TNC会话。使用全双工传输时不存在此限制。
The Posture Broker Server and Posture Broker Client MUST follow the state machine described in this section.
姿态代理服务器和姿态代理客户端必须遵循本节中描述的状态机。
PB-TNC batches are carried over protocol bindings of the PT protocol, which provides the interaction between a Posture Transport Client and a Posture Transport Server. PB-TNC counts on PT to provide a secure transport. In particular, PT MUST support mutual authentication of the Posture Transport Client and the Posture Transport Server, confidentiality and integrity protection for PB-TNC batches, and protection against replay attacks. PB-TNC is unaware of the underlying transport protocols being used. PB-TNC operates directly on PT; no further layer of PB-TNC is expected.
PB-TNC批处理通过PT协议的协议绑定进行，PT协议提供姿态传输客户端和姿态传输服务器之间的交互。PB-TNC依靠PT提供安全传输。特别是，PT必须支持姿态传输客户端和姿态传输服务器的相互身份验证、PB-TNC批次的机密性和完整性保护以及防止重播攻击。PB-TNC不知道正在使用的底层传输协议。PB-TNC直接在PT上运行；预计不会有更多的PB-TNC层。
RFC 5209 [8] describes normative requirements for the Posture Transport protocol. This section specifies additional requirements for the Posture Transport protocol. Candidate Posture Transport protocols must indicate conformance to requirements specified in this section as well as section 7.4 of RFC 5209.
RFC 5209[8]描述了姿态传输协议的规范性要求。本节规定了姿态传输协议的附加要求。候选姿态传输协议必须表明符合本节以及RFC 5209第7.4节规定的要求。
The additional requirements for candidate PT protocols are:
候选PT协议的附加要求如下：
PT-6 The PT protocol MUST be connection oriented; it MUST support confirmed initiation and close down.
PT-6 PT协议必须面向连接；它必须支持已确认的启动和关闭。
PT-7 The PT protocol MUST be able to carry binary data.
PT-7 PT协议必须能够承载二进制数据。
PT-8 The PT protocol MUST provide mechanisms for flow control and congestion control.
PT-8 PT协议必须提供流量控制和拥塞控制机制。
PT-9 PT protocol specifications MUST describe the capabilities that they provide for and limitations that they impose on the PB protocol (e.g., half/full duplex, maximum message size).
PT-9 PT协议规范必须描述其提供的功能以及对PB协议施加的限制（例如，半/全双工、最大消息大小）。
This section shows how PA messages can be carried inside a PB-TNC batch that is inside a PT protocol.
本节说明如何在PT协议内的PB-TNC批处理中携带PA消息。
Within the PT protocol, the PB-TNC header is packaged next, followed by two PB-PA messages that contain PA messages meant for the Posture Collectors and Posture Validators on the platform.
在PT协议中，接下来打包PB-TNC报头，然后是两条PB-PA消息，其中包含用于平台上姿态采集器和姿态验证器的PA消息。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PT Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-TNC Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-PA Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-PA Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PT Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-TNC Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-PA Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-PA Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Example of PB-TNC message encapsulation
图2:PB-TNC消息封装示例
This figure is conceptual, of course, and not an exact byte-for-byte replica.
当然，这个数字是概念性的，不是一个精确的逐字节复制。
This section defines the syntax and semantics of the PB-TNC protocol fields. If a Posture Broker Client or Posture Broker Server receives a batch that violates the requirements of this specification, it MUST respond by sending a fatal Invalid Parameter error in a CLOSE batch unless this document specifies otherwise.
本节定义PB-TNC协议字段的语法和语义。如果姿态代理客户端或姿态代理服务器接收到违反本规范要求的批处理，除非本文档另有规定，否则它必须通过在关闭的批处理中发送致命的无效参数错误来响应。
Every PB-TNC batch MUST start with the following header. A PB-TNC batch MUST contain only one instance of this header followed by zero or more PB-TNC messages. The PB-TNC messages are defined in subsequent sections of this specification.
每个PB-TNC批次必须从以下标题开始。PB-TNC批处理只能包含此标头的一个实例，后跟零个或多个PB-TNC消息。PB-TNC消息在本规范后续章节中定义。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version |D| Reserved | B-Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Batch Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version |D| Reserved | B-Type|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Batch Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version (8 bits)
版本（8位）
This field indicates the version of the format for the PB-TNC message. This version is intended to allow for evolution of the PB-TNC protocol in a manner that can easily be detected by message recipients.
此字段表示PB-TNC消息格式的版本。此版本旨在允许PB-TNC协议以消息接收者容易检测到的方式演进。
This field MUST be set to 2 when the batch conforms to this specification. Later versions of PB-TNC may define other values for this field. The values 0x00, 0x09, 0x0a, 0x0d, 0x20, and 0x3c are reserved and cannot be used for any version of PB-TNC to ensure that PB-TNC can be easily distinguished from earlier posture broker protocols already in use.
当批次符合本规范时，此字段必须设置为2。PB-TNC的更高版本可能会定义此字段的其他值。值0x00、0x09、0x0a、0x0d、0x20和0x3c是保留的，不能用于任何版本的PB-TNC，以确保PB-TNC可以轻松地与已在使用的早期姿态代理协议区分开来。
If a Posture Broker Client or Posture Broker Server receives a Version value that it does not support, it MUST respond with a PB-TNC batch with batch type CLOSE that contains only a fatal Version Not Supported error code and whose Version header field has the value 2. Implementations responding to a PB-TNC message containing a supported version MUST use the same Version number to minimize the risk of version incompatibility. PB-TNC message initiators that support multiple PB-TNC protocol versions SHOULD be able to alter which version of PB-TNC message they send based on prior message exchanges with a particular peer Posture Broker Client or Posture Broker Server.
如果姿态代理客户端或姿态代理服务器接收到不支持的版本值，则必须使用batch type CLOSE的PB-TNC批处理进行响应，该批处理仅包含致命版本不支持的错误代码，并且其版本头字段的值为2。响应包含受支持版本的PB-TNC消息的实现必须使用相同的版本号，以最小化版本不兼容的风险。支持多个PB-TNC协议版本的PB-TNC消息启动器应能够根据先前与特定对等姿态代理客户端或姿态代理服务器的消息交换来更改其发送的PB-TNC消息的版本。
Directionality (D) (1 bit)
方向性（D）（1位）
When a Posture Broker Client is sending this message, the Directionality bit MUST be set to 0. When a Posture Broker Server is sending this message, the Directionality bit MUST be set to 1. This helps avoid any situation where two Posture Broker Clients or two Posture Broker Servers engage in a dialog. It also helps with debugging.
当姿态代理客户端发送此消息时，方向性位必须设置为0。当姿态代理服务器发送此消息时，方向性位必须设置为1。这有助于避免出现两个姿态代理客户端或两个姿态代理服务器参与对话的情况。它还有助于调试。
Reserved (19 bits)
保留（19位）
This field is reserved. For this version of this specification, it MUST be set to 0 on transmission and ignored on reception. Future versions of this specification may allow senders to set some of these bits and recipients to interpret them.
此字段是保留的。对于本规范的此版本，必须在传输时将其设置为0，在接收时将其忽略。此规范的未来版本可能允许发送方设置其中一些位，而接收方可以解释这些位。
B-Type (Batch Type) (4 bits)
B型（批量型）（4位）
This field is used to drive the state machine described in section 3.2. This field MUST have one of the values from the following table. If any other value is received, the recipient MUST ignore the contents of the batch and send a fatal Invalid Parameter error code in a CLOSE batch. If the value received is not permitted for the current state, according to the state machine in section 3.2., the recipient MUST ignore the contents of the batch and send a fatal Unexpected Batch Type error code in a CLOSE batch.
该字段用于驱动第3.2节所述的状态机。此字段必须具有下表中的一个值。如果收到任何其他值，收件人必须忽略批处理的内容，并在关闭的批处理中发送致命的无效参数错误代码。根据第3.2节中的状态机，如果当前状态不允许接收到值，则接收方必须忽略批次的内容，并在关闭批次中发送致命的意外批次类型错误代码。
Number Name Definition
------ ---- ----------
Number Name Definition
------ ---- ----------
1 CDATA The Posture Broker Client may send a batch with this Batch Type to convey messages to the Posture Broker Server. A Posture Broker Server MUST NOT send this Batch Type. A CDATA batch may be empty (contain no messages) if the Posture Broker Client has nothing to send.
1 CDATA姿态代理客户端可以发送具有此批处理类型的批处理，以将消息传递给姿态代理服务器。姿态代理服务器不能发送此批处理类型。如果Positure Broker客户端没有要发送的内容，则CDATA批可能为空（不包含任何消息）。
2 SDATA The Posture Broker Server may send a batch with this Batch Type to convey messages to the Posture Broker Client. A Posture Broker Client MUST NOT send this Batch Type. An SDATA batch may be empty (contain no messages) if the Posture Broker Server has nothing to send.
2 SDATA姿态代理服务器可以发送此批次类型的批次，以向姿态代理客户端传递消息。姿态代理客户端不能发送此批处理类型。如果姿态代理服务器没有要发送的内容，则SDATA批可能为空（不包含任何消息）。
3 RESULT The Posture Broker Server may send a batch with this Batch Type to indicate that it has completed its evaluation. The batch MUST include a PB-Assessment-Result message and MAY include a PB-Access-Recommendation message.
3结果姿态代理服务器可能会发送具有此批次类型的批次，以表明其已完成评估。批次必须包括PB评估结果消息，并且可能包括PB访问建议消息。
4 CRETRY The Posture Broker Client may send a batch with this Batch Type to indicate that it wishes to restart an exchange. A Posture Broker Server MUST NOT send this Batch Type. A CRETRY batch may be empty (contain no messages) if the Posture Broker Client has nothing else to send.
4 CRETRY姿态代理客户端可能会发送具有此批处理类型的批处理，以指示它希望重新启动exchange。姿态代理服务器不能发送此批处理类型。如果姿态代理客户端没有其他要发送的内容，则CRETRY批可能为空（不包含任何消息）。
5 SRETRY The Posture Broker Server may send a batch with this Batch Type to indicate that it wishes to restart the exchange. A Posture Broker Client MUST NOT send this Batch Type. A SRETRY batch may be empty (contain no messages) if the Posture Broker Server has nothing else to send.
5 SRETRY姿态代理服务器可能会发送此批处理类型的批处理，以指示它希望重新启动exchange。姿态代理客户端不能发送此批处理类型。如果姿态代理服务器没有其他要发送的内容，则SRETRY批可能为空（不包含任何消息）。
6 CLOSE The Posture Broker Server or Posture Broker Client may send a batch with this Batch Type to indicate that it is about to terminate the underlying PT connection. A CLOSE batch may be empty (contain no messages) if there is nothing to send. However, if the termination is due to a fatal error, then the CLOSE batch MUST contain a PB-Error message.
6关闭姿态代理服务器或姿态代理客户端可能会发送此批次类型的批次，以指示其即将终止基础PT连接。如果没有要发送的内容，则关闭的批处理可能为空（不包含任何消息）。但是，如果终止是由于致命错误造成的，则关闭批处理必须包含PB错误消息。
Batch Length (32 bits)
批长度（32位）
This length field contains the size of the full PB-TNC batch in octets. This length includes the PB-TNC header and all the PB-TNC messages in the batch. In other words, it includes the entire contents of the batch. This field MUST contain at least the value 8 for the fixed-length fields in this header. Any Posture Broker Client or Posture Broker Server that receives a PB-TNC message with a PB-TNC Message Length field whose value is less than 8 MUST respond with a fatal Invalid Parameter error code in a CLOSE batch.
此长度字段包含完整PB-TNC批次的大小（以八位字节为单位）。此长度包括PB-TNC标头和批处理中的所有PB-TNC消息。换言之，它包括该批次的全部内容。对于此标头中的固定长度字段，此字段必须至少包含值8。任何接收PB-TNC消息长度字段值小于8的PB-TNC消息的姿态代理客户端或姿态代理服务器必须在关闭批处理中使用致命的无效参数错误代码进行响应。
All PB-TNC messages have the same overall structure, which is described in this section. Of course, the format and semantics of the PB-TNC Message Value field will vary, depending on the values of the PB-TNC Vendor ID and PB-TNC Message Type fields.
所有PB-TNC消息都具有相同的总体结构，本节对此进行了描述。当然，PB-TNC消息值字段的格式和语义会有所不同，具体取决于PB-TNC供应商ID和PB-TNC消息类型字段的值。
0 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 | PB-TNC Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-TNC Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-TNC Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-TNC Message Value (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 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 | PB-TNC Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-TNC Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-TNC Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PB-TNC Message Value (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags (8 bits)
标志（8位）
This field defines flags impacting the processing of this message.
此字段定义影响此消息处理的标志。
Bit 0 of this Flags field (the most significant bit) is known as the NOSKIP flag. If this flag is cleared (value 0), then the recipient (a Posture Broker Client or Posture Broker Server) may skip (ignore) this message if the message type is not understood or the recipient cannot or will not process the message as required in the definition of that message. If this flag is set (value 1), then recipients MUST NOT skip this attribute.
该标志字段的第0位（最高有效位）称为NOSKIP标志。如果清除此标志（值0），则如果消息类型不被理解，或者收件人无法或不会按照消息定义中的要求处理消息，则收件人（姿态代理客户端或姿态代理服务器）可能会跳过（忽略）此消息。如果设置了此标志（值1），则收件人不得跳过此属性。
This flag does not mean that all recipients must support this message. Instead, any recipient that receives a message with this flag set to 1 but cannot or will not process it as required MUST NOT act on any part of the PB-TNC batch. Instead, the recipient MUST respond with a fatal Unsupported Mandatory Message error code
此标志并不意味着所有收件人都必须支持此邮件。相反，任何接收到此标志设置为1但无法或不会按要求处理的邮件的收件人不得对PB-TNC批处理的任何部分进行操作。相反，收件人必须使用致命的不受支持的强制性消息错误代码进行响应
in a CLOSE batch. In order to avoid taking action on some messages in a batch only to later find an unsupported NOSKIP flagged message, recipients of a PB-TNC batch might choose to scan all of the messages in the batch prior to acting upon any of the messages, checking to determine whether one of them is an unsupported message with the NOSKIP flag set.
一批一批地。为了避免对批处理中的某些邮件采取操作，而只是在以后发现不受支持的NOSKIP标记邮件，PB-TNC批处理的收件人可能会选择在对任何邮件采取行动之前扫描批处理中的所有邮件，检查以确定其中一封邮件是否是设置了NOSKIP标记的不受支持邮件。
The other bits in this Flags field are reserved. For this version of PB-TNC, they MUST be set to 0 on transmission and ignored on reception.
此标志字段中的其他位保留。对于此版本的PB-TNC，在传输时必须将其设置为0，在接收时忽略。
PB-TNC Vendor ID (24 bits)
PB-TNC供应商ID（24位）
The PB-TNC Vendor ID field identifies a vendor by using the SMI Private Enterprise Number (PEN). Any organization can receive its own unique PEN from IANA, the Internet Assigned Numbers Authority. This Vendor ID qualifies the PB-TNC Message Type field so that each vendor has 2^32-1 separate message types available for their use.
PB-TNC供应商ID字段使用SMI私有企业编号（PEN）标识供应商。任何组织都可以从IANA（互联网分配号码管理机构）收到自己的唯一PEN。此供应商ID限定PB-TNC消息类型字段，以便每个供应商有2^32-1个单独的消息类型可供使用。
Message types standardized by the IETF use zero (0) in this field. The Vendor ID 0xffffff is reserved. Posture Broker Clients and Posture Broker Servers MUST NOT send messages in which the Vendor ID has this reserved value (0xffffff). If a Posture Broker Client or Posture Broker Server receives a message in which the PB-TNC Vendor ID has this reserved value (0xffffff), it MUST respond with a fatal Invalid Parameter error code in a CLOSE batch.
IETF标准化的消息类型在此字段中使用零（0）。保留供应商ID 0xffffff。姿态代理客户端和姿态代理服务器不得发送供应商ID具有此保留值（0xffffff）的消息。如果姿态代理客户端或姿态代理服务器接收到PB-TNC供应商ID具有此保留值（0xffffff）的消息，则必须在关闭批处理中使用致命的无效参数错误代码进行响应。
PB-TNC Message Type (32 bits)
PB-TNC消息类型（32位）
The PB-TNC Message Type field identifies the type of the PB-TNC message contained in the PB-TNC Message Value field. The PB-TNC message type 0xffffffff is reserved. Posture Broker Clients and Posture Broker Servers MUST NOT send messages in which the PB-TNC Message Type field has this reserved value (0xffffffff). If a Posture Broker Client or Posture Broker Server receives a message in which the PB-TNC Message Type field has this reserved value (0xffffffff), it MUST respond with a fatal Invalid Parameter error code in a CLOSE batch. Unless otherwise prohibited in the definition of a particular PB-TNC message type (e.g., PB-Language-Preference), a single PB-TNC batch may contain multiple messages with the same message type and/or vendor ID.
PB-TNC消息类型字段标识PB-TNC消息值字段中包含的PB-TNC消息的类型。PB-TNC消息类型0xFFFFFF是保留的。姿态代理客户端和姿态代理服务器不得发送PB-TNC消息类型字段具有此保留值（0xFFFFFF）的消息。如果姿态代理客户端或姿态代理服务器收到PB-TNC消息类型字段具有此保留值（0xffffffff）的消息，则必须在关闭批处理中使用致命的无效参数错误代码进行响应。除非特定PB-TNC消息类型定义中另有禁止（例如，PB语言偏好），否则单个PB-TNC批可能包含具有相同消息类型和/或供应商ID的多条消息。
The IETF and any other organization with a PEN can define 2^32-1 unique PB-TNC message types, as long as the organization's PEN is placed in the PB-TNC Vendor ID field of the message. Since the PB-TNC message type is qualified by the vendor ID, there is no
IETF和任何其他具有PEN的组织可以定义2^32-1唯一的PB-TNC消息类型，只要该组织的PEN位于消息的PB-TNC供应商ID字段中。由于PB-TNC消息类型由供应商ID限定，因此不存在
risk of conflicts as long as each organization uses its own PEN for the vendor ID and manages its own set of 2^32-1 message type values.
只要每个组织对供应商ID使用自己的笔并管理自己的一组2^32-1消息类型值，就有冲突的风险。
This document defines certain PB-TNC message types that, when used with the IETF SMI PEN (0), have standard meanings. These are known as IETF Standard PB-TNC Message Types. Some of these PB-TNC message types are mandatory and therefore MUST be implemented by all Posture Broker Client and Posture Broker Server implementations that claim compliance with this specification. For details on which PB-TNC message types are mandatory, see the description of these message types later in section 4.
本文档定义了某些PB-TNC消息类型，当与IETF SMI笔（0）一起使用时，这些消息类型具有标准含义。这些被称为IETF标准PB-TNC消息类型。其中一些PB-TNC消息类型是强制性的，因此必须由声称符合本规范的所有姿态代理客户端和姿态代理服务器实现来实现。有关哪些PB-TNC消息类型是必需的详细信息，请参阅下文第4节中对这些消息类型的描述。
IANA maintains a registry of PB-TNC message types. Entries in this registry are added by Expert Review with Specification Required, following the guidelines in section 6.1.
IANA维护PB-TNC消息类型的注册表。根据第6.1节中的指南，通过专家评审添加此注册表中的条目，并提供所需的规范。
New vendor-specific PB-TNC message types (those used with a non-zero PB-TNC vendor ID) may be defined and employed by vendors without IETF or IANA involvement. However, Posture Broker Clients and Posture Broker Servers MUST NOT require support for particular vendor-specific PB-TNC message types and MUST interoperate with other parties despite any differences in the set of vendor-specific PB-TNC message types supported (although they MAY permit administrators to configure them to require support for specific PB-TNC message types).
供应商可在不涉及IETF或IANA的情况下定义和使用新的供应商特定PB-TNC消息类型（与非零PB-TNC供应商ID一起使用）。但是，姿态代理客户端和姿态代理服务器不得要求支持特定于供应商的PB-TNC消息类型，并且必须与其他方进行互操作，尽管所支持的特定于供应商的PB-TNC消息类型集存在任何差异（尽管它们可能允许管理员将其配置为需要特定PB-TNC消息类型的支持）。
Note that the PB-TNC Message Type field is completely separate from the PA Subtype field. The same value (e.g., 0) may have different meanings as a PB-TNC message type and as a PA subtype.
请注意，PB-TNC消息类型字段与PA子类型字段完全分开。相同的值（例如，0）作为PB-TNC消息类型和PA子类型可能具有不同的含义。
PB-TNC Message Length (32 bits)
PB-TNC消息长度（32位）
This field specifies the length of this PB-TNC message in octets. It includes this header (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length). Therefore, this value MUST always be at least 12. Any Posture Broker Client or Posture Broker Server that receives a message with a PB-TNC Message Length field whose value is less than 12 MUST respond with a fatal Invalid Parameter error code in a CLOSE batch.
此字段指定此PB-TNC消息的长度（以八位字节为单位）。它包括此标头（字段标志、PB-TNC供应商ID、PB-TNC消息类型和PB-TNC消息长度）。因此，该值必须始终至少为12。任何姿态代理客户端或姿态代理服务器如果接收到值小于12的PB-TNC消息长度字段的消息，则必须在关闭批处理中以致命的无效参数错误代码进行响应。
PB-TNC Message Value (variable length)
PB-TNC消息值（可变长度）
The syntax and semantics of this field vary, depending on the values in the PB-TNC Vendor ID and PB-TNC Message Type fields. The syntax and semantics of several standard messages are defined in subsequent sections of this specification.
此字段的语法和语义因PB-TNC供应商ID和PB-TNC消息类型字段中的值而异。几个标准消息的语法和语义在本规范的后续章节中定义。
The following table provides a reference list with brief descriptions of the IETF Standard PB-TNC Message Types defined in this specification. These PB-TNC message types must be used with a PB-TNC vendor ID of zero (0). If these PB-TNC message type values are used with a different PB-TNC vendor ID, they have a completely different meaning that is not defined in this specification.
下表提供了一个参考列表，简要说明了本规范中定义的IETF标准PB-TNC消息类型。这些PB-TNC消息类型必须与零（0）的PB-TNC供应商ID一起使用。如果这些PB-TNC消息类型值与不同的PB-TNC供应商ID一起使用，则它们具有本规范中未定义的完全不同的含义。
For more details on these message types, see the remainder of section 4. For IETF Standard PA Subtypes (which are completely different from PB-TNC message types), please refer to the PA-TNC specification [10].
有关这些消息类型的更多详细信息，请参阅第4节的其余部分。对于IETF标准PA子类型（与PB-TNC消息类型完全不同），请参考PA-TNC规范[10]。
Message Type Definition
------------ ----------
0 PB-Experimental - reserved for experimental use
1 PB-PA - contains a PA message
2 PB-Assessment-Result - the overall assessment result
computed by the Posture Broker Server
3 PB-Access-Recommendation - includes Posture Broker
Server access recommendation
4 PB-Remediation-Parameters - includes Posture Broker
Server remediation parameters
5 PB-Error - error indicator
6 PB-Language-Preference - sender's preferred
language(s) for human-readable strings
7 PB-Reason-String - string explaining reason for
Posture Broker Server access recommendation
Message Type Definition
------------ ----------
0 PB-Experimental - reserved for experimental use
1 PB-PA - contains a PA message
2 PB-Assessment-Result - the overall assessment result
computed by the Posture Broker Server
3 PB-Access-Recommendation - includes Posture Broker
Server access recommendation
4 PB-Remediation-Parameters - includes Posture Broker
Server remediation parameters
5 PB-Error - error indicator
6 PB-Language-Preference - sender's preferred
language(s) for human-readable strings
7 PB-Reason-String - string explaining reason for
Posture Broker Server access recommendation
The PB-Experimental PB-TNC message type is a PB-TNC message type (value 0) that has been set aside for experimental purposes. It may be used to test code or for other experimental purposes. It MUST NOT be used in a production environment or in a product. This meaning for this PB-TNC message type only applies if the PB-TNC Vendor ID field in the PB-TNC Message Header contains the value zero (0). If a different Vendor ID is contained in that field, the PB-TNC message type 0 has a completely different meaning not defined in this specification.
PB实验PB-TNC消息类型是为实验目的而预留的PB-TNC消息类型（值0）。它可以用于测试代码或用于其他实验目的。不得在生产环境或产品中使用。此PB-TNC消息类型的含义仅在PB-TNC消息头中的PB-TNC供应商ID字段包含值零（0）时适用。如果该字段中包含不同的供应商ID，则PB-TNC消息类型0具有本规范中未定义的完全不同的含义。
The contents of the PB-TNC Message Length and PB-TNC Message Value fields for this PB-TNC message type are not specified. They may have almost any value, depending on what experiments are being conducted. Similarly, the Flags field for this message may have the NOSKIP bit set or cleared, depending on what experiments are being conducted. However, note that the PB-TNC Message Length field must have a value
未指定此PB-TNC消息类型的PB-TNC消息长度和PB-TNC消息值字段的内容。它们几乎可以有任何价值，这取决于正在进行的实验。类似地，此消息的标志字段可能设置或清除NOSKIP位，具体取决于正在进行的实验。但是，请注意，PB-TNC消息长度字段必须有一个值
of at least 12 since that is the total of the length of the fixed-length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length). Any Posture Broker Client or Posture Broker Server that receives a message with a PB-TNC Message Length field whose value is invalid MUST respond with a fatal Invalid Parameter error code in a CLOSE batch.
至少为12，因为这是PB-TNC消息开头固定长度字段的总长度（字段标志、PB-TNC供应商ID、PB-TNC消息类型和PB-TNC消息长度）。任何姿态代理客户端或姿态代理服务器如果接收到带有PB-TNC消息长度字段（其值无效）的消息，则必须在关闭批处理中以致命的无效参数错误代码进行响应。
A Posture Broker Client or Posture Broker Server implementation intended for production use MUST NOT send a message with this Message Type with the value zero (0) as the vendor ID. If it receives a message with this message type and with the value zero (0) as the vendor ID, it MUST ignore the message unless the NOSKIP bit is set, in which case it MUST respond with a fatal Unsupported Mandatory Message error code in a CLOSE batch.
用于生产用途的姿态代理客户端或姿态代理服务器实现不得发送值为零（0）作为供应商ID的此消息类型的消息。如果收到值为零（0）作为供应商ID的此消息类型的消息，则必须忽略此消息，除非设置了NOSKIP位，在这种情况下，它必须在关闭的批处理中以致命的、不受支持的强制性消息错误代码进行响应。
The PB-TNC message type named PB-PA (value 1) contains one PA message. Many batches will contain several PB-PA messages, but some batches may not contain any messages of this type.
名为PB-PA（值1）的PB-TNC消息类型包含一条PA消息。许多批将包含多条PB-PA消息，但某些批可能不包含任何此类消息。
All Posture Broker Client and Posture Broker Server implementations MUST implement support for this PB-TNC message type. Generally, this support will consist of forwarding the enclosed PA message to the appropriate Posture Collectors and Posture Validators. Specific requirements are contained later in the description of this message type.
所有姿态代理客户端和姿态代理服务器实现都必须实现对此PB-TNC消息类型的支持。通常，该支持包括将随附的PA消息转发至适当的姿势收集器和姿势验证器。此消息类型的说明后面将包含特定要求。
The type of the PA message contained in a PB-PA message is indicated by the PA Message Vendor ID and PA Subtype fields, as described later in this section. The PA-TNC specification [10] describes several standard PA message types that can be identified by the PA Message Vendor ID and PA Subtype values listed in the PA-TNC specification. Other PA message types may also be defined, as described in the description of the PA Subtype field later in this section.
PB-PA消息中包含的PA消息类型由PA消息供应商ID和PA子类型字段指示，如本节后面所述。PA-TNC规范[10]描述了可通过PA-TNC规范中列出的PA消息供应商ID和PA子类型值识别的几种标准PA消息类型。也可以定义其他PA消息类型，如本节后面PA子类型字段的说明所述。
The NOSKIP flag in the PB-TNC Message Header MUST be set for this message type. Any Posture Broker Client or Posture Broker Server that receives a PB-PA message with the NOSKIP flag not set MUST ignore the message and MUST respond with a fatal Invalid Parameter error code in a CLOSE batch.
必须为此消息类型设置PB-TNC消息头中的NOSKIP标志。接收到未设置NOSKIP标志的PB-PA消息的任何姿态代理客户端或姿态代理服务器必须忽略该消息，并且必须在关闭批处理中使用致命的无效参数错误代码进行响应。
For the PB-PA message type, the PB-TNC Vendor ID field MUST contain the value zero (0) and the PB-TNC Message Type field MUST contain 1. If a non-zero value is contained in the PB-TNC Vendor ID field, message type 1 has a completely different meaning not defined in this specification.
对于PB-PA消息类型，PB-TNC供应商ID字段必须包含值零（0），PB-TNC消息类型字段必须包含1。如果PB-TNC供应商ID字段中包含非零值，则消息类型1具有本规范中未定义的完全不同的含义。
The PB-TNC Message Length field MUST contain the length of the entire PB-TNC message, including the fixed-length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length), the fixed-length fields listed below (Flags, PA Message Vendor ID, PA Subtype, Posture Collector Identifier, and Posture Validator Identifier), and the PA Message Body. Since the PA Message Body is variable length, the value in the PB-TNC Message Length field will vary also. However, it MUST always be at least 24 to cover the fixed-length fields listed in the preceding sentences. Any Posture Broker Client or Posture Broker Server that receives a PB-PA message with a PB-TNC Message Length field that has an invalid value MUST respond with a fatal Invalid Parameter error code in a CLOSE batch.
PB-TNC消息长度字段必须包含整个PB-TNC消息的长度，包括PB-TNC消息开头的固定长度字段（字段标志、PB-TNC供应商ID、PB-TNC消息类型和PB-TNC消息长度）、下面列出的固定长度字段（标志、PA消息供应商ID、PA子类型、姿势收集器标识符和姿势验证器标识符），和PA消息正文。由于PA消息正文是可变长度的，PB-TNC消息长度字段中的值也会有所不同。但是，它必须始终至少为24，以涵盖前面句子中列出的固定长度字段。任何接收PB-TNC消息长度的PB-PA消息的姿态代理客户端或姿态代理服务器具有无效值的h字段必须在关闭批处理中以致命的无效参数错误代码响应。
The following diagram illustrates the format and contents of the PB-TNC Message Value field for this message type. The text after this diagram describes the fields shown here.
下图说明了此消息类型的PB-TNC消息值字段的格式和内容。此图后面的文本描述了此处显示的字段。
0 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 | PA Message Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA Subtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Posture Collector Identifier | Posture Validator Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA Message Body (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 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 | PA Message Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA Subtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Posture Collector Identifier | Posture Validator Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PA Message Body (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags (8 bits)
标志（8位）
This field contains flags relating to the PA message.
此字段包含与PA消息相关的标志。
Bit 0 of this flags field (the most significant bit) is known as the EXCL flag (for exclusive). If the EXCL bit is cleared (value 0), the Posture Broker Client or Posture Broker Server that receives this PB-TNC message SHOULD deliver the PA message contained in this PB-TNC message to all Posture Collectors or Posture Validators that have expressed an interest in PA messages with this PA Message Vendor ID and PA subtype. If a Posture Broker Client receives a message with the EXCL flag set (value 1), the Posture Broker Client SHOULD deliver the PA message contained in this PB-TNC message only to the Posture Collector identified by the Posture Collector Identifier field. However, if the identified Posture Collector has not expressed an interest in PA messages with this PA Message Vendor ID and PA subtype, the PA
此标志字段的第0位（最高有效位）称为EXCL标志（用于排他）。如果清除EXCL位（值0），则接收此PB-TNC消息的姿态代理客户端或姿态代理服务器应将此PB-TNC消息中包含的PA消息传递给已表示对具有此PA消息供应商ID和PA子类型的PA消息感兴趣的所有姿态收集器或姿态验证器。如果姿态代理客户端接收到设置了EXCL标志（值1）的消息，则姿态代理客户端应仅将此PB-TNC消息中包含的PA消息传递给姿态收集器标识符字段标识的姿态收集器。但是，如果识别的姿态收集器未表示对具有此PA消息供应商ID和PA子类型的PA消息感兴趣，则PA
message should be silently discarded. Analogous requirements apply to a Posture Broker Server that receives a message with the EXCL flag set.
消息应该被悄悄地丢弃。类似的要求也适用于接收带有EXCL标志集的消息的姿态代理服务器。
The EXCL bit allows, for example, a Posture Validator to handle the circumstance where there are two Posture Collectors on the endpoint that are interested in a particular kind of PA messages and the Posture Validator has remediation instructions that only apply to one of those Posture Collectors.
例如，EXCL位允许姿势验证器处理端点上有两个对特定种类的PA消息感兴趣的姿势收集器的情况，并且姿势验证器具有仅适用于其中一个姿势收集器的修正指令。
The other bits in this Flags field are reserved. For this version of PB-TNC, they MUST be set to 0 on transmission and ignored on reception.
此标志字段中的其他位保留。对于此版本的PB-TNC，在传输时必须将其设置为0，在接收时忽略。
PA Message Vendor ID (24 bits)
PA消息供应商ID（24位）
The PA Message Vendor ID field identifies a vendor by using the SMI Private Enterprise Number (PEN). Any organization can receive its own unique PEN from IANA, the Internet Assigned Numbers Authority. The PA Message Vendor ID qualifies the PA Subtype field so that each vendor has 2^32-1 separate PA subtypes available for its use. PA subtypes standardized by the IETF are always used with a PA Message Vendor ID of the value zero (0) in this field. The PA Message Vendor ID 0xffffff is reserved. A Posture Broker Client or Posture Broker Server MUST NOT send messages in which the PA Message Vendor ID field has this reserved value (0xffffff). If a Posture Broker Client or Posture Broker Server receives a message in which the PA Message Vendor ID has this reserved value (0xffffff), it MUST respond with a fatal Invalid Parameter error code in a CLOSE batch.
PA消息供应商ID字段使用SMI私有企业编号（PEN）标识供应商。任何组织都可以从IANA（互联网分配号码管理机构）收到自己的唯一PEN。PA消息供应商ID限定PA子类型字段，以便每个供应商有2^32-1个单独的PA子类型可供其使用。IETF标准化的PA子类型始终与此字段中值为零（0）的PA消息供应商ID一起使用。PA消息供应商ID 0xffffff是保留的。姿态代理客户端或姿态代理服务器不得发送PA消息供应商ID字段具有此保留值（0xffffff）的消息。如果姿态代理客户端或姿态代理服务器接收到PA消息供应商ID具有此保留值（0xffffff）的消息，则必须在关闭批处理中使用致命的无效参数错误代码进行响应。
PA Subtype (32 bits)
PA子类型（32位）
The PA Subtype field identifies the type of the PA message contained in the PA Message Body field. The PA subtype 0xffffffff is reserved. A Posture Broker Client or Posture Broker Server MUST NOT send messages in which the PA Subtype field has this reserved value (0xffffffff). If a Posture Broker Client or Posture Broker Server receives a message in which the PA Subtype has this reserved value (0xffffffff), it MUST respond with a fatal Invalid Parameter error code in a CLOSE batch. A Posture Broker Client or Posture Broker Server MUST support having multiple PA messages in a single PB-TNC batch that have the same PA subtype and/or PA Message Vendor ID.
PA子类型字段标识PA消息正文字段中包含的PA消息的类型。PA子类型0xFFFFFF是保留的。姿态代理客户端或姿态代理服务器不得发送PA子类型字段具有此保留值（0xFFFFFF）的消息。如果姿态代理客户端或姿态代理服务器接收到PA子类型具有此保留值（0xFFFFFF）的消息，则必须在关闭批处理中使用致命的无效参数错误代码进行响应。姿态代理客户端或姿态代理服务器必须支持在单个PB-TNC批处理中具有多个PA消息，这些消息具有相同的PA子类型和/或PA消息供应商ID。
IANA maintains a registry of PA subtypes. Entries in this registry are added by Expert Review with Specification Required, following the guidelines in section 6.1. No PA subtypes are
IANA维护PA子类型的注册表。根据第6.1节中的指南，通过专家评审添加此注册表中的条目，并提供所需的规范。不存在PA亚型
defined in this specification. Definitions of IETF Standard PA Subtypes are contained in the PA-TNC specification [10] and other specifications. IETF Standard PA Subtypes are always used with a PA Message Vendor ID of zero (0).
在本规范中定义。IETF标准PA子类型的定义包含在PA-TNC规范[10]和其他规范中。IETF标准PA子类型始终与零（0）的PA消息供应商ID一起使用。
New vendor-specific PA subtypes (those used with a non-zero PA Message Vendor ID) may be defined and employed by vendors without IETF or IANA involvement. However, Posture Broker Clients and Posture Broker Servers MUST NOT require support for particular vendor-specific PA subtypes and MUST interoperate with other parties despite any differences in the set of vendor-specific PA subtypes supported (although they MAY permit administrators to configure them to require support for specific PA subtypes).
供应商可在不涉及IETF或IANA的情况下定义和使用新的供应商特定PA子类型（与非零PA消息供应商ID一起使用）。但是，姿态代理客户端和姿态代理服务器不得要求支持特定的供应商特定PA子类型，并且必须与其他方进行互操作，尽管所支持的供应商特定PA子类型集存在任何差异（尽管它们可能允许管理员将其配置为需要支持特定的PA子类型）。
Note that the PB-TNC Message Type field is completely separate from the PA Subtype field. The same value (e.g., 0) may have different meanings as a PB-TNC message type and as a PA subtype.
请注意，PB-TNC消息类型字段与PA子类型字段完全分开。相同的值（例如，0）作为PB-TNC消息类型和PA子类型可能具有不同的含义。
Posture Collector Identifier (16 bits)
姿态采集器标识符（16位）
The Posture Collector Identifier field contains the identifier of the Posture Collector associated with this PA message.
姿态收集器标识符字段包含与此PA消息关联的姿态收集器的标识符。
The Posture Broker Client is responsible for assigning one or more Posture Collector Identifier values (but not 0xffff) to each Posture Collector involved in a message exchange. Multiple Posture Collector identifiers are required for appropriate correlation in cases where there are multiple components of the same type handled by a single Posture Collector, e.g., an endpoint with two VPN client implementations handled by a single VPN Posture Collector. Please refer to section 3.3 of the PA-TNC specification for an example that illustrates the use of multiple Posture Collector Identifiers. The Posture Collector Identifier value(s) assigned to a Posture Collector by a Posture Broker Client MUST NOT change during the course of a PT session. This identifier is used to identify a unique Posture Collector communicating with the Posture Broker Client on the endpoint during a NEA exchange, and is used by the Posture Validator to send response attributes to a specific Posture Collector component if required.
姿态代理客户端负责为消息交换中涉及的每个姿态收集器分配一个或多个姿态收集器标识符值（但不是0xffff）。在存在由单个姿态采集器处理的相同类型的多个组件的情况下，需要多个姿态采集器标识符来进行适当的关联，例如，具有由单个VPN姿态采集器处理的两个VPN客户端实现的端点。请参阅PA-TNC规范第3.3节，以了解说明多姿态采集器标识符使用的示例。姿态代理客户端分配给姿态采集器的姿态采集器标识符值在PT会话过程中不得更改。此标识符用于标识在NEA交换期间与端点上的姿态代理客户端通信的唯一姿态采集器，并由姿态验证器用于在需要时向特定姿态采集器组件发送响应属性。
When a Posture Broker Server sets the EXCL flag for a PA message, the Posture Broker Server MUST set the Posture Collector Identifier field to the identifier of the Posture Collector that should receive the PA message. If the EXCL flag is not set, a Posture Broker Server MAY still set the Posture Collector Identifier value for PA messages that it sends to indicate that the PA message is intended as a response to a message sent by the
当姿态代理服务器为PA消息设置EXCL标志时，姿态代理服务器必须将姿态收集器标识符字段设置为应接收PA消息的姿态收集器的标识符。如果未设置EXCL标志，则姿态代理服务器仍可为其发送的PA消息设置姿态收集器标识符值，以指示PA消息旨在作为对用户发送的消息的响应
Posture Collector associated with the specified Posture Collector Identifier. If the Posture Broker Server does not wish to indicate any Posture Collector in this manner, it SHOULD set this field to the reserved value 0xffff.
与指定姿势收集器标识符关联的姿势收集器。如果姿态代理服务器不希望以这种方式指示任何姿态收集器，则应将此字段设置为保留值0xffff。
Posture Validator Identifier (16 bits)
姿势验证器标识符（16位）
The Posture Validator Identifier field contains the identifier of the Posture Validator associated with this PA message.
姿势验证器标识符字段包含与此PA消息关联的姿势验证器的标识符。
The Posture Broker Server MUST assign a unique Posture Validator Identifier value (but not 0xffff) to each Posture Validator involved in a message exchange and include this Posture Validator identifier in this field for any PA messages sent by that Posture Validator. The Posture Validator Identifier value assigned to a Posture Validator by a Posture Broker Server MUST NOT change during the course of a PT session. This identifier is used to identify a unique Posture Validator communicating with the Posture Broker Server endpoint during a NEA exchange, and is used by the Posture Collector to send attributes to a specific Posture Validator if required.
姿态代理服务器必须为消息交换中涉及的每个姿态验证器分配一个唯一的姿态验证器标识符值（但不是0xffff），并在该字段中为该姿态验证器发送的任何PA消息包含该姿态验证器标识符。姿态代理服务器分配给姿态验证器的姿态验证器标识符值在PT会话过程中不得更改。此标识符用于标识在NEA交换期间与姿态代理服务器端点通信的唯一姿态验证器，姿态收集器使用该标识符在需要时向特定姿态验证器发送属性。
When a Posture Broker Client sets the EXCL flag for a PA message, the Posture Broker Client MUST set the Posture Validator Identifier field to the identifier of the Posture Validator that should receive the PA message. If the EXCL flag is not set, a Posture Broker Client MAY still set the Posture Validator Identifier value for PA messages that it sends to indicate that the PA message is intended as a response to a message sent by the Posture Validator associated with the specified Posture Validator Identifier. If the Posture Broker Client does not wish to indicate any Posture Validator in this manner, it SHOULD set this field to the reserved value 0xffff.
当姿态代理客户端为PA消息设置EXCL标志时，姿态代理客户端必须将姿态验证器标识符字段设置为应接收PA消息的姿态验证器的标识符。如果未设置EXCL标志，则姿势代理客户端仍可为其发送的PA消息设置姿势验证器标识符值，以指示PA消息旨在作为对与指定姿势验证器标识符相关联的姿势验证器发送的消息的响应。如果姿态代理客户端不希望以这种方式指示任何姿态验证器，则应将此字段设置为保留值0xffff。
PA Message Body (variable length)
PA消息正文（可变长度）
The PA Message Body field contains the body of the PA message that is being carried in this PB-TNC message. The length of this field can be determined by subtracting the length of the fixed-length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length) and the fixed-length fields at the start of the PB-PA message (Flags, PA Message Vendor ID, PA Subtype, Posture Collector Identifier, and Posture Validator Identifier) from the message length contained in the PB-TNC Message Length field. The length of these fixed-length fields is 24 octets. Therefore, any Posture Broker Client or Posture Broker Server that receives a PB-PA message with
PA消息正文字段包含此PB-TNC消息中承载的PA消息正文。此字段的长度可通过减去PB-TNC消息开头的固定长度字段（字段标志、PB-TNC供应商ID、PB-TNC消息类型和PB-TNC消息长度）和PB-PA消息开头的固定长度字段来确定（标志、PA消息供应商ID、PA子类型、姿态收集器标识符和姿态验证器标识符）来自包含在PB-TNC消息长度字段中的消息长度。这些固定长度字段的长度为24个八位字节。因此，接收PB-PA消息的任何姿态代理客户端或姿态代理服务器
a PB-TNC Message Length field whose value is less than 24 MUST respond with a fatal Invalid Parameter error code in a CLOSE batch.
值小于24的PB-TNC消息长度字段必须在关闭批处理中以致命的无效参数错误代码进行响应。
The PB-TNC message type named PB-Assessment-Result (value 2) is used by the Posture Broker Server to provide the assessment result after the Posture Broker Server has completed the assessment of the endpoint. The Posture Broker Server will typically compute the assessment result as a cumulative of the individual assessment results received from the various Posture Validators; the algorithm for computation of assessment result at the Posture Broker layer is implementation specific and can also change based on policies in a specific deployment. The Posture Broker Server MUST include one message of this type in any batch of type RESULT and MUST NOT include a message of this type in any other type of batch. The Posture Broker Client MUST NOT send a PB-TNC message with this message type. If a Posture Broker Server receives a PB-TNC message with this message type, it MUST respond with a fatal Invalid Parameter error in a CLOSE batch. The Posture Broker Client MUST implement and process this message and MUST ignore any message with this message type that is not part of a batch of type RESULT.
在姿态代理服务器完成端点评估后，姿态代理服务器使用名为PB Assessment Result（值2）的PB-TNC消息类型提供评估结果。姿态代理服务器通常将评估结果计算为从各种姿态验证器接收的单个评估结果的累积值；在姿态代理层计算评估结果的算法是特定于实现的，也可以根据特定部署中的策略进行更改。姿态代理服务器必须在任何类型的批处理结果中包含一条此类型的消息，并且不得在任何其他类型的批处理中包含此类型的消息。姿态代理客户端不得发送具有此消息类型的PB-TNC消息。如果姿态代理服务器接收到此消息类型的PB-TNC消息，它必须在关闭批处理中以致命的无效参数错误进行响应。姿态代理客户端必须实现和处理此消息，并且必须忽略任何不属于批处理结果类型的具有此消息类型的消息。
The NOSKIP flag in the PB-TNC Message Header MUST be set for this message type. The PB-TNC Vendor ID field MUST contain the value zero (0) and the PB-TNC Message Type field MUST contain 2. If a non-zero value is contained in the PB-TNC Vendor ID field, message type 2 has a completely different meaning not defined in this specification. The PB-TNC Message Length field MUST contain the value 16 since that is the total of the length of the fixed-length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length) along with the Assessment Result field described below. Any Posture Broker Client or Posture Broker Server that receives a PB-Assessment-Result message with a PB-TNC Message Length field that does not have a value of 16 MUST respond with a fatal Invalid Parameter error code in a CLOSE batch.
必须为此消息类型设置PB-TNC消息头中的NOSKIP标志。PB-TNC供应商ID字段必须包含值零（0），PB-TNC消息类型字段必须包含值2。如果PB-TNC供应商ID字段中包含非零值，则消息类型2具有本规范中未定义的完全不同的含义。PB-TNC消息长度字段必须包含值16，因为这是PB-TNC消息开头的固定长度字段的总长度（字段标志、PB-TNC供应商ID、PB-TNC消息类型和PB-TNC消息长度）以及下面描述的评估结果字段。收到PB评估结果消息且PB-TNC消息长度字段值不为16的任何姿态代理客户端或姿态代理服务器必须在关闭批处理中以致命的无效参数错误代码进行响应。
The following diagram illustrates the format and contents of the PB-TNC Message Value field for this message type. The text after this diagram describes the fields shown here.
下图说明了此消息类型的PB-TNC消息值字段的格式和内容。此图后面的文本描述了此处显示的字段。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assessment Result |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Assessment Result |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Assessment Result
评估结果
This 32-bit field MUST contain one of the following values
此32位字段必须包含以下值之一
Value Description
----- -----------
0 Posture Broker Server assessed the endpoint to be
compliant with policy.
Value Description
----- -----------
0 Posture Broker Server assessed the endpoint to be
compliant with policy.
1 Posture Broker Server assessed the endpoint to be non-compliant with policy but the difference from compliance was minor.
1服务器评估终结点不符合策略，但与符合性的差异很小。
2 Posture Broker Server assessed the endpoint to be non-compliant with policy and the assessed difference from compliance was very significant.
2 Position Broker Server评估端点不符合策略，评估结果与符合性差异非常显著。
3 Posture Broker Server was unable to determine policy compliance due to an error.
3由于出现错误，代理服务器无法确定策略符合性。
4 Posture Broker Server was unable to determine whether the assessed endpoint is compliant with policy based on the attributes provided by endpoint.
4代理服务器无法根据端点提供的属性确定评估的端点是否符合策略。
If a Posture Broker Client receives an Assessment Result value other than the five values described above, it MUST respond with a fatal Invalid Parameter error in a CLOSE batch. Other values may be defined in future versions of PB-TNC but only if the PB-TNC version number is changed. Therefore, there is no need for an IANA registry for Assessment Result values.
如果姿态代理客户端收到除上述五个值之外的评估结果值，则它必须在结束批处理中以致命的无效参数错误进行响应。其他值可在PB-TNC的未来版本中定义，但前提是PB-TNC版本号已更改。因此，评估结果值不需要IANA注册表。
The PB-TNC message type named PB-Access-Recommendation (value 3) is used by the Posture Broker Server to provide an access recommendation after the Posture Broker Server has completed some assessment of the endpoint. The PB-Assessment-Result and the PB-Access-Recommendation attribute together constitute the global assessment decision for an endpoint. The PB-Access-Recommendation is not authoritative, and the network and host-based access control systems would typically use additional information to determine the network access that is granted to the endpoint. The Posture Broker Server MAY include one message of this type in any batch of type RESULT and MUST NOT include a message of this type in any other type of batch. Posture Broker Clients MUST NOT send a PB-TNC message with this message type. If a Posture Broker Server receives a PB-TNC message with this message type, it MUST respond with a fatal Invalid Parameter error in a CLOSE
在姿态代理服务器完成对端点的某些评估后，姿态代理服务器使用名为PB访问建议（值3）的PB-TNC消息类型提供访问建议。PB评估结果和PB访问建议属性共同构成端点的全局评估决策。PB访问建议没有权威性，基于网络和主机的访问控制系统通常会使用附加信息来确定授予端点的网络访问。姿态代理服务器可以在任何类型的批处理结果中包含一条此类型的消息，并且不得在任何其他类型的批处理中包含此类型的消息。姿态代理客户端不得发送此消息类型的PB-TNC消息。如果姿态代理服务器接收到此消息类型的PB-TNC消息，它必须在关闭时以致命的无效参数错误进行响应
batch. The Posture Broker Client MUST implement and process this message and MUST ignore any message with this message type that is not part of a batch of type RESULT.
一批姿态代理客户端必须实现和处理此消息，并且必须忽略任何不属于批处理结果类型的具有此消息类型的消息。
The NOSKIP flag in the PB-TNC Message Header MUST NOT be set for this message type. Any Posture Broker Client or Posture Broker Server that receives a PB-Access-Recommendation message with the NOSKIP flag set MUST ignore the message and MUST respond with a fatal Invalid Parameter error code in a CLOSE batch. The PB-TNC Vendor ID field MUST contain the value zero (0) and the PB-TNC Message Type field MUST contain 3. If a non-zero value is contained in the PB-TNC Vendor ID field, message type 3 has a completely different meaning not defined in this specification. The PB-TNC Message Length field MUST contain the value 16 since that is the total of the length of the fixed-length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length) along with the Access Recommendation field described below. Any Posture Broker Client or Posture Broker Server that receives a PB-Access-Recommendation message with a PB-TNC Message Length field that does not have a value of 16 MUST respond with a fatal Invalid Parameter error code in a CLOSE batch.
不能为此消息类型设置PB-TNC消息头中的NOSKIP标志。接收到设置了NOSKIP标志的PB访问建议消息的任何姿态代理客户端或姿态代理服务器都必须忽略该消息，并且必须在关闭的批处理中使用致命的无效参数错误代码进行响应。PB-TNC供应商ID字段必须包含值零（0），PB-TNC消息类型字段必须包含值3。如果PB-TNC供应商ID字段中包含非零值，则消息类型3具有本规范中未定义的完全不同的含义。PB-TNC消息长度字段必须包含值16，因为这是PB-TNC消息开头的固定长度字段的总长度（字段标志、PB-TNC供应商ID、PB-TNC消息类型和PB-TNC消息长度）以及下面描述的访问建议字段。任何姿态代理客户端或姿态代理服务器如果接收到PB访问建议消息且PB-TNC消息长度字段的值不为16，则必须在关闭批处理中以致命的无效参数错误代码进行响应。
The following diagram illustrates the format and contents of the PB-TNC Message Value field for this message type. The text after this diagram describes the fields shown here.
下图说明了此消息类型的PB-TNC消息值字段的格式和内容。此图后面的文本描述了此处显示的字段。
0 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 | Access Recommendation Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 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 | Access Recommendation Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved (16 bits)
保留（16位）
These Reserved bits MUST be set to 0 on transmission and ignored on reception.
这些保留位必须在传输时设置为0，在接收时忽略。
Access Recommendation Code (16 bits)
访问建议代码（16位）
The Access Recommendation Code field identifies the Access Recommendation that the Posture Broker Server has made for this Posture Broker Client at this time. This field MUST have one of these three values: 1 for Access Allowed (full access), 2 for Access Denied (no access), or 3 for Quarantined (partial access). If a Posture Broker Client receives an Access Recommendation Code value other than these three values, it MUST respond with a fatal Invalid Parameter error code in a CLOSE batch. Other values may
Access Recommension Code（访问建议代码）字段标识姿态代理服务器此时为此姿态代理客户端提出的访问建议。此字段必须具有以下三个值之一：1表示允许访问（完全访问），2表示拒绝访问（无访问），或3表示隔离访问（部分访问）。如果姿态代理客户端接收到除这三个值之外的访问建议代码值，它必须在关闭批处理中以致命的无效参数错误代码进行响应。其他值可能会改变
be defined in future versions of PB-TNC but only if the PB-TNC version number is changed. Therefore, there is no need for an IANA registry for Access Recommendation Codes.
在PB-TNC的未来版本中定义，但仅在PB-TNC版本号更改时定义。因此，访问建议代码不需要IANA注册表。
The PB-TNC message type named PB-Remediation-Parameters (value 4) is used by the Posture Broker Server to provide global (not Posture Validator-specific) remediation parameters after the Posture Broker Server has completed some assessment of the endpoint. The Posture Broker Server MAY include one or more messages of this type in any batch of any type, but this message type is most useful in batches of type RESULT.
在姿态代理服务器完成对端点的某些评估后，姿态代理服务器使用名为PB修正参数（值4）的PB-TNC消息类型提供全局（非特定于姿态验证器）修正参数。姿态代理服务器可以在任何类型的任何批中包含一个或多个此类型的消息，但此消息类型在结果类型的批中最有用。
The Posture Broker Client MUST NOT send a PB-TNC message with this message type. If a Posture Broker Server receives a PB-TNC message with this message type, it MUST respond with a fatal Invalid Parameter error in a CLOSE batch. The Posture Broker Client may implement and process this message but is not required to do so. It may skip this message. Even if the Posture Broker Client implements this message type, it is not obligated to act on it.
姿态代理客户端不得发送具有此消息类型的PB-TNC消息。如果姿态代理服务器接收到此消息类型的PB-TNC消息，它必须在关闭批处理中以致命的无效参数错误进行响应。姿态代理客户端可以实现和处理此消息，但不需要这样做。它可能会跳过此消息。即使姿态代理客户端实现了此消息类型，它也没有义务对其进行操作。
The NOSKIP flag in the PB-TNC Message Header MUST NOT be set for this message type. The PB-TNC Vendor ID field MUST contain the value zero (0) and the PB-TNC Message Type field MUST contain 4. If a non-zero value is contained in the PB-TNC Vendor ID field, message type 4 has a completely different meaning not defined in this specification.
不能为此消息类型设置PB-TNC消息头中的NOSKIP标志。PB-TNC供应商ID字段必须包含值零（0），PB-TNC消息类型字段必须包含值4。如果PB-TNC供应商ID字段中包含非零值，则消息类型4具有本规范中未定义的完全不同的含义。
The PB-TNC Message Length field MUST contain the length of the entire PB-TNC message, including the fixed-length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length), the fixed-length fields listed below (Reserved, Remediation Parameters Vendor ID, and Remediation Parameters Type), and the Remediation Parameters. Since the Remediation Parameters field is variable length, the value in the PB-TNC Message Length field will vary also. However, it MUST always be at least 20 to cover the fixed-length fields listed in the preceding sentences. Any Posture Broker Client that receives a PB-Remediation-Parameters message with a PB-TNC Message Length field that contains an invalid value (e.g., less than 20) MUST respond with a fatal Invalid Parameter error code in a CLOSE batch.
PB-TNC消息长度字段必须包含整个PB-TNC消息的长度，包括PB-TNC消息开头的固定长度字段（字段标志、PB-TNC供应商ID、PB-TNC消息类型和PB-TNC消息长度）、下面列出的固定长度字段（保留、修正参数供应商ID和修正参数类型），和修正参数。由于修正参数字段是可变长度的，PB-TNC消息长度字段中的值也会有所不同。但是，它必须始终至少为20，以涵盖前面句子中列出的固定长度字段。任何接收PB-TN的PB修正参数消息的姿态代理客户端C包含无效值（例如，小于20）的消息长度字段必须在关闭批处理中以致命的无效参数错误代码响应。
The following diagram illustrates the format and contents of the PB-TNC Message Value field for this message type. The text after this diagram describes the fields shown here.
下图说明了此消息类型的PB-TNC消息值字段的格式和内容。此图后面的文本描述了此处显示的字段。
0 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 | Remediation Parameters Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remediation Parameters Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remediation Parameters (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 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 | Remediation Parameters Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remediation Parameters Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remediation Parameters (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved (8 bits)
保留（8位）
These Reserved bits MUST be set to 0 on transmission and ignored on reception.
这些保留位必须在传输时设置为0，在接收时忽略。
Remediation Parameters Vendor ID (24 bits)
补救参数供应商ID（24位）
The Remediation Parameters Vendor ID field identifies a vendor by using the SMI Private Enterprise Number (PEN). Any organization can receive its own unique PEN from IANA, the Internet Assigned Numbers Authority. The Remediation Parameters Vendor ID qualifies the Remediation Parameters Type field so that each vendor has 2^32 separate Remediation Parameters Types available for its use. Remediation Parameters Types standardized by the IETF are always used with the value zero (0) in this field.
补救参数供应商ID字段使用SMI私有企业编号（PEN）标识供应商。任何组织都可以从IANA（互联网分配号码管理机构）收到自己的唯一PEN。修正参数供应商ID限定修正参数类型字段，以便每个供应商有2^32个单独的修正参数类型可供其使用。IETF标准化的修复参数类型始终与该字段中的值零（0）一起使用。
Remediation Parameters Type (32 bits)
修正参数类型（32位）
The Remediation Parameters Type field identifies the type of remediation parameters contained in the Remediation Parameters field. A Posture Broker Client or Posture Broker Server MUST support having multiple Remediation Parameters messages contained in a single PB-TNC batch that have the same Remediation Parameters Type and/or Remediation Parameters Vendor ID.
修正参数类型字段标识修正参数字段中包含的修正参数类型。姿态代理客户端或姿态代理服务器必须支持在单个PB-TNC批处理中包含多个修正参数消息，这些消息具有相同的修正参数类型和/或修正参数供应商ID。
IANA maintains a registry of PB-TNC Remediation Parameters Types. Entries in this registry are added by Expert Review with Specification Required, following the guidelines in section 6.1. A list of IETF Standard PB-TNC Remediation Parameters Types defined in this specification appears later in this section.
IANA维护PB-TNC修复参数类型的注册表。根据第6.1节中的指南，通过专家评审添加此注册表中的条目，并提供所需的规范。本节后面将列出本规范中定义的IETF标准PB-TNC修复参数类型列表。
New vendor-specific Remediation Parameters Types (those used with a non-zero Remediation Parameters vendor ID) may be defined and employed by vendors without IETF or IANA involvement. However, Posture Broker Clients and Posture Broker Servers MUST NOT require support for particular vendor-specific Remediation Parameters Types and MUST interoperate with other parties despite any differences in the set of vendor-specific Remediation Parameters
供应商可在不涉及IETF或IANA的情况下定义和使用新的供应商特定补救参数类型（与非零补救参数供应商ID一起使用）。但是，姿态代理客户端和姿态代理服务器不得要求支持特定供应商特定的修正参数类型，并且必须与其他方互操作，尽管供应商特定的修正参数集存在任何差异
Types supported (although they MAY permit administrators to configure them to require support for specific Remediation Parameters Types).
支持的类型（尽管它们可能允许管理员将其配置为需要特定修正参数类型的支持）。
Note that the Remediation Parameters Type is completely separate from the PB-TNC Message Type and the PA Subtype fields. The same value (e.g., 0) may have different meanings in each of these fields.
请注意，修正参数类型与PB-TNC消息类型和PA子类型字段完全不同。相同的值（例如，0）在每个字段中可能具有不同的含义。
Remediation Parameters (variable length)
修正参数（可变长度）
The Remediation Parameters field contains the actual remediation parameters carried in this PB-TNC message. The length of this field can be determined by subtracting the length of the fixed-length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length) and the fixed-length fields at the start of the PB-Remediation-Parameters message (Reserved, Remediation Parameters Vendor ID, and Remediation Parameters Type) from the message length contained in the PB-TNC Message Length field. The length of these fixed-length fields is 20 octets. Therefore, any Posture Broker Client that receives a PB-Remediation-Parameters message with a PB-TNC Message Length field whose value is less than 20 MUST consider this a malformed message. The Posture Broker Client MUST respond with a fatal Invalid Parameter error code in a CLOSE batch.
修正参数字段包含此PB-TNC消息中携带的实际修正参数。此字段的长度可以通过减去PB-TNC消息开头的固定长度字段（字段标志、PB-TNC供应商ID、PB-TNC消息类型和PB-TNC消息长度）和PB-TNC消息开头的固定长度字段的长度来确定（保留、修正参数供应商ID和修正参数类型）从PB TNC消息长度字段中包含的消息长度。这些固定长度字段的长度是20个八位字节。因此，任何接收PB TCNE消息长度消息的PosialBuffer-Client客户机，其值小于20的PB-TCNC消息长度字段必须认为这是一个畸形消息。关闭批处理中存在致命的无效参数错误代码。
This subsection defines several Remediation Parameters Types that have been standardized by the IETF.
本小节定义了IETF标准化的几种修复参数类型。
Remediation-URI
补救URI
This Remediation Parameters Type is employed by creating a PB-Remediation-Parameters message with a Remediation Parameters Vendor ID equal to the value zero (0) and a Remediation Parameters Type of 1. The Remediation Parameters field in the PB-Remediation-Parameters message MUST contain a URI, as described in RFC 3986 [2]. This URI contains instructions and resources for remediation. The Posture Broker Client MAY load the URI and display the resulting web page to the user. The Posture Broker Client MAY also ignore the URI or take another action with it. The Posture Broker Server and any other parties involved in configuring this remediation URI should consider the likely capabilities of the Posture Broker Client when creating the URI
此修正参数类型通过创建修正参数供应商ID等于值零（0）且修正参数类型为1的PB修正参数消息来使用。PB修正参数消息中的修正参数字段必须包含URI，如RFC 3986[2]所述。此URI包含用于修正的说明和资源。姿态代理客户端可以加载URI并向用户显示结果网页。姿态代理客户端还可以忽略URI或对其执行其他操作。在配置URI时，姿态代理服务器和任何其他参与方在创建URI时应考虑姿态代理客户端的可能功能。
and the content referenced by the URI. For example, they should consider the Posture Broker Client's language preferences as expressed in the PB-Language-Preference message.
以及URI引用的内容。例如，他们应该考虑在PB语言偏好消息中表达的姿态代理客户端的语言偏好。
Remediation-String
修复字符串
This Remediation Parameters Type is employed by creating a PB-Remediation-Parameters message with a Remediation Parameters Vendor ID equal to the value zero (0) and a Remediation Parameters Type of 2. The Remediation Parameters field in the PB-Remediation-Parameters message MUST contain the structure defined below, which contains human-readable instructions for remediation.
此修正参数类型通过创建修正参数供应商ID等于零（0）且修正参数类型为2的PB修正参数消息来使用。PB修正参数消息中的修正参数字段必须包含以下定义的结构，其中包含人类可读的修正指令。
The Posture Broker Client MAY display the instructions to the user. The Posture Broker Client MAY also ignore the instructions or take another action with them. The Posture Broker Server and any other parties involved in configuring these instructions should consider the likely capabilities of the Posture Broker Client when creating the instructions. For example, they should consider the Posture Broker Client's language preferences as expressed in the PB-Language-Preference message.
姿态代理客户端可以向用户显示指令。姿态代理客户端也可能忽略这些指示或对其采取其他操作。StaseBooAgent服务器和配置这些指令所涉及的任何其他各方应考虑在创建指令时姿态代理客户端的可能功能。例如，他们应该考虑在PB语言偏好消息中表达的姿态代理客户端的语言偏好。
The following diagram illustrates the format and contents of the Remediation Parameters field when carrying a Remediation-String parameter. The text after this diagram describes the fields shown here.
下图说明了携带修正字符串参数时修正参数字段的格式和内容。此图后面的文本描述了此处显示的字段。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remediation String Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remediation String (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lang Code Len | Remediation String Lang Code (Variable Len) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remediation String Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remediation String (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lang Code Len | Remediation String Lang Code (Variable Len) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Remediation String Length (32 bits)
修正字符串长度（32位）
The Remediation String Length contains the length of the Remediation String field in octets.
修正字符串长度包含修正字符串字段的长度（以八位字节为单位）。
Remediation String (variable length)
修正字符串（可变长度）
The Remediation String field MUST contain a UTF-8 [6] encoded string. This string contains human-readable instructions for remediation that MAY be displayed to the user by the Posture Broker Client. NUL termination MUST NOT be included. If a
修正字符串字段必须包含UTF-8[6]编码字符串。此字符串包含可由姿态代理客户端向用户显示的人类可读的修正说明。不得包括NUL终止。如果
Posture Broker Client receives a Reason String that does contain a NUL termination, it MUST respond with a fatal Invalid Parameter error in a CLOSE batch.
姿态代理客户端收到包含NUL终止的原因字符串，它必须在关闭批处理中以致命的无效参数错误进行响应。
Lang Code Len (8 bits)
语言代码Len（8位）
The Lang Code Len field contains the length of the Remediation String Lang Code field in octets. This value may be set to zero to indicate that the language code for the Remediation String field is not known.
Lang Code Len字段包含修复字符串Lang Code字段的长度（以八位字节为单位）。此值可以设置为零，以指示修正字符串字段的语言代码未知。
Remediation String Lang Code (variable length)
修正字符串语言代码（可变长度）
The Remediation String Lang Code field contains a US-ASCII string composed of a well-formed RFC 4646 [3] language tag that indicates the language(s) used in the Remediation String in the Remediation Parameters field. A zero-length string may be sent for this field (essentially omitting this field) to indicate that the language code for the Remediation String field is not known.
修正字符串Lang Code字段包含一个US-ASCII字符串，该字符串由格式良好的RFC 4646[3]语言标记组成，该标记指示修正参数字段中修正字符串中使用的语言。可能会为此字段发送长度为零的字符串（基本上忽略此字段），以指示修正字符串字段的语言代码未知。
The PB-TNC message type named PB-Error (value 5) is used by the Posture Broker Client or Posture Broker Server to indicate that an error has occurred. The Posture Broker Client or Posture Broker Server MAY include one or more messages of this type in any batch of any type. Other messages may also be included in the same batch. The party that receives a PB-Error message MAY log it or take other action as deemed appropriate. If the FATAL flag is set (value 1), the recipient MUST terminate the PB-TNC session after processing the batch without sending any messages in response. Every Posture Broker Client and Posture Broker Server MUST implement this message type.
姿态代理客户端或姿态代理服务器使用名为PB Error（值5）的PB-TNC消息类型指示已发生错误。姿态代理客户端或姿态代理服务器可以在任何类型的任何批中包括一个或多个该类型的消息。其他消息也可能包含在同一批中。收到PB错误消息的一方可记录该消息或采取其他适当的措施。如果设置了致命标志（值1），则收件人必须在处理批处理后终止PB-TNC会话，而不发送任何响应消息。每个姿态代理客户端和姿态代理服务器都必须实现此消息类型。
The NOSKIP flag in the PB-TNC Message Header MUST be set for this message type. The PB-TNC Vendor ID field MUST contain the value zero (0) and the PB-TNC Message Type field MUST contain 5. If a non-zero value is contained in the PB-TNC Vendor ID field, message type 5 has a completely different meaning not defined in this specification.
必须为此消息类型设置PB-TNC消息头中的NOSKIP标志。PB-TNC供应商ID字段必须包含值零（0），PB-TNC消息类型字段必须包含值5。如果PB-TNC供应商ID字段中包含非零值，则消息类型5具有本规范中未定义的完全不同的含义。
The PB-TNC Message Length field MUST contain the length of the entire PB-TNC message, including the fixed-length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length), the fixed-length fields listed below (Flags, Error Code Vendor ID, Error Code, and Reserved), and the Error Parameters. Since the Error Parameters field is variable length, the value in the PB-TNC Message Length field will vary also.
PB-TNC消息长度字段必须包含整个PB-TNC消息的长度，包括PB-TNC消息开头的固定长度字段（字段标志、PB-TNC供应商ID、PB-TNC消息类型和PB-TNC消息长度）、下面列出的固定长度字段（标志、错误代码供应商ID、错误代码和保留），以及误差参数。由于错误参数字段长度可变，PB-TNC消息长度字段中的值也会变化。
However, it MUST always be at least 20 to cover the fixed-length fields listed in the preceding sentences. Any Posture Broker Client or Posture Broker Server that receives a PB-Error message with a PB-TNC Message Length field that contains an invalid value (e.g., less than 20) MUST respond with a fatal Invalid Parameter error code in a CLOSE batch. Any PB-Error message generated while processing a PB-Error message MUST be a fatal error to avoid the chance of generating an infinite loop of errors.
但是，它必须始终至少为20才能覆盖前面句子中列出的固定长度字段。任何姿态代理客户端或姿态代理服务器如果接收到包含无效值（例如小于20）的PB-TNC消息长度字段的PB错误消息，则必须在关闭批处理中使用致命的无效参数错误代码进行响应。在处理PB错误消息时生成的任何PB错误消息都必须是致命错误，以避免生成无限循环的错误。
The following diagram illustrates the format and contents of the PB-TNC Message Value field for this message type. The text after this diagram describes the fields shown here.
下图说明了此消息类型的PB-TNC消息值字段的格式和内容。此图后面的文本描述了此处显示的字段。
0 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 | Error Code Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Parameters (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 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 | Error Code Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Parameters (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Flags (8 bits)
标志（8位）
This field defines flags relating to the error.
此字段定义与错误相关的标志。
Bit 0 of this flags field (the most significant bit) is known as the FATAL flag. If the FATAL bit is cleared (value 0), the Posture Broker Client or Posture Broker Server that receives this PB-TNC message SHOULD process this error and then continue with the exchange. If the FATAL flag is set (value 1), the Posture Broker Client or Posture Broker Server that receives this PB-TNC message MUST terminate the exchange after processing the error. In addition, any Posture Broker Client or Posture Broker Server that sends a fatal error MUST NOT process the batch that caused the error and MUST terminate the exchange after sending the batch containing the error report. A PB-Error message with the FATAL flag set MUST always be sent in a CLOSE batch since the sender will be terminating the exchange immediately after sending the batch.
此标志字段的第0位（最高有效位）称为致命标志。如果清除了致命位（值0），则接收此PB-TNC消息的姿态代理客户端或姿态代理服务器应处理此错误，然后继续交换。如果设置了致命标志（值1），则接收此PB-TNC消息的姿态代理客户端或姿态代理服务器必须在处理错误后终止交换。此外，任何发送致命错误的姿态代理客户端或姿态代理服务器不得处理导致错误的批处理，并且必须在发送包含错误报告的批处理后终止exchange。设置了致命标志的PB错误消息必须始终在关闭批中发送，因为发送方将在发送批后立即终止交换。
The FATAL bit allows a Posture Broker Client or Posture Broker Server to signal a fatal error (like an invalid batch type) and/or a non-fatal error (like an invalid language tag for a preferred language).
致命位允许姿态代理客户端或姿态代理服务器发出致命错误（如无效的批处理类型）和/或非致命错误（如首选语言的无效语言标记）的信号。
The other bits in this Flags field are reserved. For this version of PB-TNC, they MUST be set to 0 on transmission and ignored on reception.
此标志字段中的其他位保留。对于此版本的PB-TNC，在传输时必须将其设置为0，在接收时忽略。
Error Code Vendor ID (24 bits)
错误代码供应商ID（24位）
The Error Code Vendor ID field identifies a vendor by using the SMI Private Enterprise Number (PEN). Any organization can receive its own unique PEN from IANA, the Internet Assigned Numbers Authority. The Error Code Vendor ID qualifies the Error Code field so that each vendor has 2^16 separate Error Codes available for its use. Error codes standardized by the IETF are always used with the value zero (0) in this field. For detailed descriptions of those messages, see the next few subsections.
错误代码供应商ID字段使用SMI私有企业编号（PEN）标识供应商。任何组织都可以从IANA（互联网分配号码管理机构）收到自己的唯一PEN。错误代码供应商ID限定错误代码字段，以便每个供应商有2^16个单独的错误代码可供使用。IETF标准化的错误代码始终与该字段中的值零（0）一起使用。有关这些消息的详细描述，请参见下面的几个小节。
Error Code (16 bits)
错误代码（16位）
The Error Code field identifies the type of error being signaled with this message. The format of the Error Parameters field depends on the value of the Error Code Vendor ID and the Error Code. However, any recipient that does not understand a particular error code can process the error fairly well by using the FATAL flag to determine whether the error is fatal and the PB-TNC Message Length to skip over the Error Parameters field (or log it).
Error Code（错误代码）字段标识用此消息发出信号的错误类型。错误参数字段的格式取决于错误代码供应商ID和错误代码的值。但是，任何不了解特定错误代码的收件人都可以通过使用致命标志来确定错误是否为致命错误，并使用PB-TNC消息长度跳过错误参数字段（或记录），从而很好地处理错误。
IANA maintains a registry of PB-TNC Error Codes. Entries in this registry are added by Expert Review with Specification Required, following the guidelines in section 6.1. A list of IETF Standard PB-TNC Error Codes defined in this specification appears later in section 4.9.1.
IANA维护PB-TNC错误代码的注册表。根据第6.1节中的指南，通过专家评审添加此注册表中的条目，并提供所需的规范。本规范中定义的IETF标准PB-TNC错误代码列表见下文第4.9.1节。
New vendor-specific error codes (those used with a non-zero error code vendor ID) may be defined and employed by vendors without IETF or IANA involvement. Posture Broker Clients and Posture Broker Servers that receive an unknown error code MUST process this error code gracefully by ignoring or logging it if it is not marked as fatal and terminating the exchange if it is marked as fatal.
供应商可在不涉及IETF或IANA的情况下定义和使用新的供应商特定错误代码（与非零错误代码供应商ID一起使用的错误代码）。接收未知错误代码的姿态代理客户端和姿态代理服务器必须优雅地处理此错误代码，如果未标记为致命错误代码，则忽略或记录它；如果标记为致命错误代码，则终止交换。
Reserved (16 bits)
保留（16位）
The Reserved bits MUST be set to 0 on transmission and ignored on reception.
传输时保留位必须设置为0，接收时忽略。
The following error codes are IETF Standard PB-TNC Error Codes, hence the Error Code Vendor ID MUST be the value zero (0). The following table defines the 16-bit error code. Vendor-specific error codes may be defined by setting the Error Code Vendor ID to the defining vendor's SMI PEN and setting the Error Code field to whatever error code(s) that vendor has defined. The format, length, and meaning of the Error Parameters field varies, based on the Error Code Vendor ID and Error Code. Subsequent sections of this document define the format, length, and meaning of the Error Parameters for the IETF Standard PB-TNC Error Codes defined in this section.
以下错误代码为IETF标准PB-TNC错误代码，因此错误代码供应商ID的值必须为零（0）。下表定义了16位错误代码。供应商特定的错误代码可通过将错误代码供应商ID设置为定义供应商的SMI笔，并将错误代码字段设置为供应商定义的任何错误代码来定义。错误参数字段的格式、长度和含义因错误代码供应商ID和错误代码而异。本文件后续章节定义了本节中定义的IETF标准PB-TNC错误代码的错误参数的格式、长度和含义。
Error Code Definition
---------- ----------
0 Unexpected Batch Type. Error Parameters are empty.
Error Code Definition
---------- ----------
0 Unexpected Batch Type. Error Parameters are empty.
1 Invalid Parameter. Error Parameters has offset where invalid value was found.
1无效参数。错误参数具有发现无效值的偏移量。
2 Local Error. Error Parameters are empty.
2局部错误。错误参数为空。
3 Unsupported Mandatory Message. Error Parameters has offset of offending PB-TNC Message
3不支持的强制消息。错误参数具有出错PB-TNC消息的偏移量
4 Version Not Supported. Error Parameters has information about which versions are supported.
4版本不受支持。错误参数包含有关支持哪些版本的信息。
This section defines the format, length, and meaning of the Error Parameters field for the IETF Standard PB-TNC Error Codes defined in this specification.
本节定义了本规范中定义的IETF标准PB-TNC错误代码的错误参数字段的格式、长度和含义。
The Error Parameters field is zero length for the IETF Standard PB-TNC Error Code 0. The FATAL flag MUST be set for this error code.
IETF标准PB-TNC错误代码0的错误参数字段长度为零。必须为此错误代码设置致命标志。
The Error Parameters field has the following structure for the IETF Standard PB-TNC Error Code 1. The Offset field is the offset in octets from the start of the PB-TNC batch to the invalid value. The FATAL flag may be either set or cleared for this error code.
对于IETF标准PB-TNC错误代码1，错误参数字段具有以下结构。偏移量字段是从PB-TNC批次开始到无效值的偏移量（以八位字节为单位）。可以为此错误代码设置或清除致命标志。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Error Parameters field is zero length for the IETF Standard PB-TNC Error Code 2. The FATAL flag MUST be set for this error code.
IETF标准PB-TNC错误代码2的错误参数字段长度为零。必须为此错误代码设置致命标志。
The Error Parameters field has the following structure for the IETF Standard PB-TNC Error Code 3. The Offset field is the offset in octets from the start of the PB-TNC batch to the PB-TNC message whose message type was not recognized (and where the NOSKIP flag was set). The FATAL flag MUST be set for this error code.
对于IETF标准PB-TNC错误代码3，错误参数字段具有以下结构。偏移量字段是从PB-TNC批处理开始到消息类型未被识别（并且设置了NOSKIP标志）的PB-TNC消息之间的偏移量（以八位字节为单位）。必须为此错误代码设置致命标志。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Error Parameters field has the following structure for the IETF Standard PB-TNC Error Code 4. The FATAL flag MUST be set for this error code.
对于IETF标准PB-TNC错误代码4，错误参数字段具有以下结构。必须为此错误代码设置致命标志。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bad Version | Max Version | Min Version | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bad Version | Max Version | Min Version | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Bad Version field is the version number that was received and is not supported. The Max Version and Min Version fields indicate which PB-TNC version numbers are supported by the sender of the error code. The sender MUST support all PB-TNC versions between the Min Version and the Max Version, inclusive (i.e., including the Min Version and the Max Version) but excluding the reserved versions listed in section 4.1. The Reserved field MUST be set to 0 on transmission and ignored upon reception. When possible, recipients of this error code SHOULD send future messages to the Posture Broker Server or Posture Broker Client that originated this error message with a PB-TNC version number within the stated range.
“错误版本”字段是收到的版本号，不受支持。“最大版本”和“最小版本”字段表示错误代码发送者支持哪些PB-TNC版本号。发送方必须支持最低版本和最高版本之间的所有PB-TNC版本（包括最低版本和最高版本），但不包括第4.1节中列出的保留版本。传输时保留字段必须设置为0，接收时忽略。在可能的情况下，此错误代码的收件人应将未来的消息发送给产生此错误消息的姿态代理服务器或姿态代理客户端，其PB-TNC版本号在规定的范围内。
Any party that is sending the Version Not Supported error code MUST include that error code as the only PB-TNC message in a PB-TNC CLOSE batch with version number 2. All parties that send PB-TNC batches SHOULD be able to properly process a batch that meets this description, even if they cannot process any other aspect of PB-TNC version 2. This ensures that a PB-TNC version exchange can proceed properly, no matter what versions of PB-TNC the parties implement.
发送版本不受支持错误代码的任何一方必须将该错误代码作为版本号为2的PB-TNC关闭批处理中的唯一PB-TNC消息包含在内。发送PB-TNC批次的所有各方应能够正确处理符合本说明的批次，即使他们无法处理PB-TNC版本2的任何其他方面。这确保了PB-TNC版本交换能够正常进行，无论双方实施的PB-TNC版本是什么。
The PB-TNC message type named PB-Language-Parameters (value 6) is used by the Posture Broker Client to indicate which language or languages it would prefer for any human-readable strings that might be sent to it. This allows the Posture Broker Server and Posture Validators to adapt any messages they may send to the Posture Broker Client's preferences (probably determined by the language preferences of the endpoint's users).
姿态代理客户端使用名为PB语言参数（值6）的PB-TNC消息类型来指示对于可能发送给它的任何人类可读字符串，它更喜欢哪种语言。这允许姿态代理服务器和姿态验证器调整它们可能发送给姿态代理客户端首选项的任何消息（可能由端点用户的语言首选项决定）。
The Posture Broker Server may also send this message type to the Posture Broker Client to indicate the Posture Broker Server's language preferences, but this is not very useful since the Posture Broker Client rarely sends human-readable strings to the Posture Broker Server and, if it does, rarely can adapt those strings to the preferences of the Posture Broker Server.
姿态代理服务器还可以向姿态代理客户端发送此消息类型，以指示姿态代理服务器的语言首选项，但这不是很有用，因为姿态代理客户端很少向姿态代理服务器发送人类可读的字符串，如果发送，则，很少有人能够使这些字符串适应姿态代理服务器的首选项。
No Posture Broker Client or Posture Broker Server is required to send or implement this message type. However, a Posture Broker Server SHOULD attempt to adapt to user language preferences by implementing this message type, passing the language preference information to Posture Validators, and allowing administrators to configure human-readable languages in whatever languages are preferred by their users.
发送或实现此消息类型不需要姿态代理客户端或姿态代理服务器。但是，姿态代理服务器应尝试通过实现此消息类型、将语言首选项信息传递给姿态验证器以及允许管理员以用户首选的任何语言配置人类可读的语言来适应用户语言首选项。
A Posture Broker Client or Posture Broker Server may include a message of this type in any batch of any type. However, it is suggested that this message be included in the first batch sent by the Posture Broker Client or Posture Broker Server in a PB-TNC session so that the recipient can start adapting its human-readable messages as soon as possible. If one PB-Language-Parameters message is received and then another one is received in a later batch for the same PB-TNC session, the value included in the later message should be considered to replace the value in the earlier message.
姿态代理客户端或姿态代理服务器可以在任何类型的任何批中包含此类型的消息。但是，建议将此消息包括在PB-TNC会话中由姿态代理客户端或姿态代理服务器发送的第一批消息中，以便接收方能够尽快开始调整其人类可读的消息。如果收到一条PB语言参数消息，然后在同一PB-TNC会话的下一批中收到另一条，则应考虑用后一条消息中包含的值替换前一条消息中的值。
A Posture Broker Client or Posture Broker Server MUST NOT include more than one message of this type in a single batch. If a Posture Broker Client or Posture Broker Server receives more than one message of this type in a single batch, it should ignore all but the last one.
姿态代理客户端或姿态代理服务器在单个批处理中不得包含多个此类消息。如果一个姿态代理客户端或姿态代理服务器在一个批处理中接收到多个此类消息，它应该忽略除最后一个之外的所有消息。
The NOSKIP flag in the PB-TNC Message Header MUST NOT be set for this message type. The PB-TNC Vendor ID field MUST contain the value zero (0) and the PB-TNC Message Type field MUST contain 6. If a non-zero value is contained in the PB-TNC Vendor ID field, message type 6 has a completely different meaning not defined in this specification.
不能为此消息类型设置PB-TNC消息头中的NOSKIP标志。PB-TNC供应商ID字段必须包含值零（0），PB-TNC消息类型字段必须包含值6。如果PB-TNC供应商ID字段中包含非零值，则消息类型6具有本规范中未定义的完全不同的含义。
The PB-TNC Message Length field MUST contain the length of the entire PB-TNC message, including the fixed-length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length) and the Language Preference field. Since the Language Preference field is variable length, the value in the PB-TNC Message Length field will vary also. However, it MUST always be at least 12 to cover the fixed-length fields listed in the preceding sentences.
PB-TNC消息长度字段必须包含整个PB-TNC消息的长度，包括PB-TNC消息开头的固定长度字段（字段标志、PB-TNC供应商ID、PB-TNC消息类型和PB-TNC消息长度）和语言首选项字段。由于语言首选项字段是可变长度的，PB-TNC消息长度字段中的值也会变化。但是，它必须始终至少为12才能覆盖前面句子中列出的固定长度字段。
The following diagram illustrates the format and contents of the PB-TNC Message Value field for this message type. The text after this diagram describes the fields shown here.
下图说明了此消息类型的PB-TNC消息值字段的格式和内容。此图后面的文本描述了此处显示的字段。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Language Preference (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Language Preference (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Language Preference (variable length)
语言首选项（可变长度）
The Language Preference field contains an Accept-Language header, as described in RFC 3282 [4] (using the RFC 2234 ABNF definition of Accept-Language included in that RFC, US-ASCII only, no control characters allowed, no comments, no NUL termination). Any Posture Broker Client or Posture Broker Server that sends a PB-Language-Preference message MUST ensure that the Language Preference field conforms to this format. For example, one acceptable value would be "Accept-Language: fr, en" (without the quote marks).
语言首选项字段包含一个接受语言标题，如RFC 3282[4]中所述（使用RFC中包含的接受语言的RFC 2234 ABNF定义，仅限US-ASCII，不允许使用控制字符，无注释，无NUL终止）。发送PB语言首选项消息的任何姿态代理客户端或姿态代理服务器必须确保语言首选项字段符合此格式。例如，一个可接受的值是“Accept Language:fr，en”（不带引号）。
A zero-length Language Preference field indicates that no language preference information is available. Generally, there's no need to send a PB-Language-Preference message with a zero-length Language Preference field since this is equivalent to sending no PB-Language-Preference message at all, but it may be useful to send a zero-length Language Preference field if a PB-Language-Preference message with a non-zero-length Language Preference field was sent in an earlier batch but these preferences no longer apply.
长度为零的语言首选项字段表示没有可用的语言首选项信息。通常，不需要发送带有零长度语言首选项字段的PB语言首选项消息，因为这相当于根本不发送PB语言首选项消息，但是，如果在早期批处理中发送了具有非零长度语言首选项字段的PB语言首选项消息，但这些首选项不再适用，则发送零长度语言首选项字段可能很有用。
The PB-TNC message type named PB-Reason-String (value 7) is used by the Posture Broker Server to provide a human-readable explanation for the global assessment decision conveyed in the PB-Assessment-Result & PB-Access-Recommendation messages. Therefore, a PB-Reason-String
姿态代理服务器使用名为PB Reason String（值7）的PB-TNC消息类型为PB评估结果和PB访问建议消息中传达的全局评估决策提供人类可读的解释。因此，需要一个PB原因字符串
message SHOULD only be included in the same batch as the PB-Assessment-Result and PB-Access-Recommendation message. The Posture Broker Client MUST NOT ever send a PB-Reason-String message.
消息只能与PB评估结果和PB访问建议消息包含在同一批中。姿态代理客户端不得发送PB原因字符串消息。
The Posture Broker Client is not required to implement this message type and the Posture Broker Server is not required to send it. However, there is some benefit to doing so since users are often curious about why the endpoint was considered non-compliant. The manner in which a Posture Broker Client uses this field is up to the implementer and not specified here. The Posture Broker Client MAY display the message to the user, log it, ignore it, or take any other action that is not inconsistent with the requirements of this specification. Since the strings contained in this message are human-readable, the Posture Broker Server SHOULD adapt them to the Posture Broker Client's language preferences as expressed in any PB-Language-Preference message sent by the Posture Broker Client in this PB-TNC session.
不需要姿态代理客户端来实现此消息类型，也不需要姿态代理服务器来发送它。但是，这样做有一些好处，因为用户经常好奇为什么端点被视为不兼容。姿态代理客户端使用此字段的方式由实现者决定，此处未指定。姿态代理客户端可以向用户显示消息、记录消息、忽略消息或采取与本规范要求不一致的任何其他操作。由于此消息中包含的字符串是人类可读的，因此姿态代理服务器应根据姿态代理客户端在此PB-TNC会话中发送的任何PB语言首选项消息中表示的姿态代理客户端的语言首选项对其进行调整。
A Posture Broker Server MAY include more than one message of this type in any batch of any type. However, it is suggested that this message be included in the same batch as the PB-Assessment-Result and PB-Access-Recommendation message. If more than one PB-Reason-String message is included in a single batch, the Posture Broker Client SHOULD consider the strings included in these messages to be equivalent in meaning. This allows the Posture Broker Server to return multiple equivalent reason strings in different languages, which may help if the Posture Broker Server is not able to accommodate the Posture Broker Client's language preferences.
姿态代理服务器可以在任何类型的任何批中包含多个此类型的消息。但是，建议将此消息与PB评估结果和PB访问建议消息包含在同一批中。如果不止一个PB原因字符串消息包含在一个批处理中，那么StHuffer-Buffer-Client应该考虑这些消息中包含的字符串在意义上是等价的。这允许姿态代理服务器以不同的语言返回多个等效的原因字符串，如果姿态代理服务器无法适应姿态代理客户端的语言首选项，这可能会有所帮助。
The NOSKIP flag in the PB-TNC Message Header MUST NOT be set for this message type. The PB-TNC Vendor ID field MUST contain the value zero (0) and the PB-TNC Message Type field MUST contain 7. If a non-zero value is contained in the PB-TNC Vendor ID field, message type 7 has a completely different meaning not defined in this specification.
不能为此消息类型设置PB-TNC消息头中的NOSKIP标志。PB-TNC供应商ID字段必须包含值零（0），PB-TNC消息类型字段必须包含值7。如果PB-TNC供应商ID字段中包含非零值，则消息类型7具有本规范中未定义的完全不同的含义。
The PB-TNC Message Length field MUST contain the length of the entire PB-TNC message, including the fixed-length fields at the start of the PB-TNC message (the fields Flags, PB-TNC Vendor ID, PB-TNC Message Type, and PB-TNC Message Length), the fixed-length fields listed below (Reason String Length and Lang Code Len), and the Reason String and Reason String Language Code fields. Since the Reason String and Reason String Language Code fields are variable length, the value in the PB-TNC Message Length field will vary also. However, it MUST always be at least 17 to cover the fixed-length fields listed in the preceding sentences. In fact, the PB-TNC Message Length field MUST be exactly the sum of 17 (for the fixed-length fields) and the values
PB-TNC消息长度字段必须包含整个PB-TNC消息的长度，包括PB-TNC消息开头的固定长度字段（字段标志、PB-TNC供应商ID、PB-TNC消息类型和PB-TNC消息长度）、下面列出的固定长度字段（原因字符串长度和语言代码长度），以及原因字符串和原因字符串语言代码字段。由于原因字符串和原因字符串语言代码字段的长度可变，PB-TNC消息长度字段中的值也会有所不同。但是，它必须始终至少为17才能覆盖前面句子中列出的固定长度字段。事实上，PB-TNC消息长度字段必须正好是17（对于固定长度字段）和值的总和
of the Reason String Length and Lang Code Len fields. If this is not the case, the recipient MUST respond with a fatal Invalid Parameter error code in a CLOSE batch.
原因字符串长度和Lang Code Len字段。如果不是这种情况，则收件人必须在关闭批处理中使用致命的无效参数错误代码进行响应。
The following diagram illustrates the format and contents of the PB-TNC Message Value field for this message type. The text after this diagram describes the fields shown here.
下图说明了此消息类型的PB-TNC消息值字段的格式和内容。此图后面的文本描述了此处显示的字段。
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason String Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason String (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lang Code Len | Reason String Language Code (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason String Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason String (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lang Code Len | Reason String Language Code (Variable Length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reason String Length (32 bits)
原因字符串长度（32位）
The Reason String Length field contains the length of the Reason String field in octets.
原因字符串长度字段包含原因字符串字段的长度（以八位字节为单位）。
Reason String (variable length)
原因字符串（可变长度）
The Reason String field contains a UTF-8 encoded string that provides a human-readable reason for the Posture Broker Server's assessment decision. NUL termination MUST NOT be included. If a Posture Broker Client receives a Reason String that does contain a NUL termination, it MUST respond with a fatal Invalid Parameter error code in a CLOSE batch. A zero-length string MUST NOT be sent since this is the same as sending no reason string at all, leaving the reason unspecified.
“原因字符串”字段包含一个UTF-8编码字符串，该字符串为姿态代理服务器的评估决策提供了一个人类可读的原因。不得包括NUL终止。如果姿态代理客户端接收到包含NUL终止的原因字符串，它必须在关闭批处理中以致命的无效参数错误代码进行响应。不能发送长度为零的字符串，因为这与根本不发送原因字符串相同，未指定原因。
Lang Code Len (8 bits)
语言代码Len（8位）
The Lang Code Len field contains the length of the Reason String Language Code field in octets.
Lang Code Len字段包含原因字符串语言代码字段的长度（以八位字节为单位）。
Reason String Language Code (variable length)
原因字符串语言代码（可变长度）
The Reason String Language Code field contains a US-ASCII string containing a well-formed RFC 4646 [3] language tag that indicates the language(s) used in the Reason String in this message. NUL termination MUST NOT be included in this field. A zero-length string MAY be sent for this field (essentially omitting this field) to indicate that the language code for the reason string is not known.
“原因字符串语言代码”字段包含一个US-ASCII字符串，其中包含格式良好的RFC 4646[3]语言标记，该标记指示此消息中原因字符串中使用的语言。此字段中不得包含NUL终止。可以为此字段发送长度为零的字符串（基本上忽略此字段），以指示原因字符串的语言代码未知。
PT is required and assumed to provide reliable and secure transport for the PB-TNC protocol (including authentication, confidentiality, integrity protection, and replay protection). Still, it is useful to describe the possible threats to PB-TNC and the countermeasures that are or can be employed. This section does that.
PT被要求并假定为PB-TNC协议提供可靠和安全的传输（包括身份验证、机密性、完整性保护和重播保护）。尽管如此，描述PB-TNC可能面临的威胁以及目前或可以采取的对策仍然是有用的。本节就是这样做的。
There are several possible threats to the PB-TNC protocol.
PB-TNC协议可能存在几种威胁。
Untrusted intermediaries on the network between the NEA Client and the NEA Server may attempt to observe data sent between the Posture Broker Client and the Posture Broker Server via PB-TNC, modify this data in transit, reorder it, or replay it. They may also attempt to mount a denial-of-service attack against either party or truncate the exchange prematurely. If successful, these attacks may result in improper assessment decisions relating to the NEA Client, failure to reassess these decisions in light of changed circumstances, improper remediation instructions sent to the NEA Client (which could lead to the compromise of the NEA Client), unauthorized access to confidential information about the NEA Client's health and/or identity, improper reason strings or other messages that might be displayed to the user, access to reusable credentials such as posture assertions, denial of service on the NEA Client, and even complete denial of access to the network (if a denial-of-service attack against the NEA Server was successful and the network required permission from the NEA Server to grant network access).
NEA客户端和NEA服务器之间的网络上的不受信任的中间人可能会尝试观察姿态代理客户端和姿态代理服务器之间通过PB-TNC发送的数据，在传输过程中修改该数据，对其重新排序或重播。他们还可能试图对任何一方发起拒绝服务攻击或过早截断交换。如果成功，这些攻击可能会导致与NEA客户相关的不当评估决定、未能根据变化的情况重新评估这些决定、发送给NEA客户的不当补救指令（这可能导致NEA客户受损），未经授权访问有关NEA客户端健康和/或身份的机密信息、不正确的原因字符串或可能显示给用户的其他消息、访问可重用凭据（如姿态断言）、拒绝NEA客户端上的服务，甚至完全拒绝访问网络（如果针对NEA服务器的拒绝服务攻击成功，并且网络需要NEA服务器的许可才能授予网络访问权）。
Trusted intermediaries between the Posture Broker Client and the Posture Broker Server include the Posture Transport Client and the Posture Transport Server. These parties are considered trusted because they are responsible for properly implementing the security protections provided by PT. If they fail to do so properly, these security protections may be diminished or eliminated altogether. The possible attacks are the same as those listed in the previous paragraph. To give one fairly likely example, if a Posture Transport Client fails to properly authenticate and authorize the Posture Transport Server (whether through implementation error or through user configuration to "trust anyone"), the improperly authorized Posture Transport Server may mount any of the previously described attacks against the NEA Client.
姿态代理客户端和姿态代理服务器之间的可信中介包括姿态传输客户端和姿态传输服务器。这些当事人被认为是受信任的，因为他们负责正确实施PT提供的安全保护。如果他们不能正确地这样做，这些安全保护可能会被削弱或完全消除。可能的攻击与上一段中列出的攻击相同。举一个很可能的例子，如果姿态传输客户端未能正确验证和授权姿态传输服务器（无论是由于实现错误还是通过用户配置“信任任何人”），未经适当授权的姿态传输服务器可能会对NEA客户端发起任何上述攻击。
Compromise of any of the trusted parties (the Posture Broker Client, the Posture Transport Client, the Posture Broker Server, or the Posture Transport Server) may result in failures that are equivalent to those listed in the first paragraph. These failures may be even
任何受信任方（姿态代理客户端、姿态传输客户端、姿态代理服务器或姿态传输服务器）的泄露可能导致与第一段中列出的故障相同的故障。这些失败可能更严重
more dangerous since they will not be detectable by observing network traffic or by examining and comparing audit logs. Failure to properly secure communications between the Posture Broker Client and the Posture Transport Client or between the Posture Broker Server and the Posture Transport Server is usually indistinguishable from compromise of those parties. Compromise of the operating system or other critical software, firmware, or hardware components on the NEA Client or NEA Server will typically result in an equivalent result. And an attacker's ability to gain privileged access to the NEA Client or NEA Server (even for a brief time, long enough to disable or misconfigure security settings) is generally equivalent as well. If the NEA Client or NEA Server are dependent on other services for their proper operation (including Posture Collectors, Posture Validators, directories, and patch management services), compromise of those services may result in compromise or failure of the dependent parties. Of course, compromise or failure of NEA Server components is most serious since this would probably affect a large number of NEA Clients while the effects of NEA Client compromise might well be limited to a single machine.
更危险的是，通过观察网络流量或检查和比较审核日志，无法检测到它们。姿态代理客户端和姿态传输客户端之间或姿态代理服务器和姿态传输服务器之间的通信未能正确安全，通常无法区分这两方的危害。NEA客户端或NEA服务器上的操作系统或其他关键软件、固件或硬件组件受损通常会导致相同的结果。攻击者获得对NEA客户端或NEA服务器的特权访问的能力（即使是很短的时间，也足以禁用或错误配置安全设置）通常是等效的。如果NEA客户端或NEA服务器的正常运行依赖于其他服务（包括姿态采集器、姿态验证器、目录和补丁管理服务），这些服务的泄露可能会导致相关方的泄露或失败。当然，NEA服务器组件的泄露或故障最为严重，因为这可能会影响大量NEA客户端，而NEA客户端泄露的影响可能仅限于一台机器。
The primary countermeasure against attacks by untrusted network intermediaries is the security provided by the PT protocol. Any candidate PT protocols should be carefully examined to ensure that all the threats described above are adequately addressed.
针对不可信网络中介攻击的主要对策是PT协议提供的安全性。应仔细检查任何候选PT协议，以确保上述所有威胁得到充分解决。
As noted above, compromise or erroneous operation of any of the trusted parties is a serious matter with substantial security implications. This includes the Posture Broker Client, the Posture Broker Server, the Posture Transport Client, and the Posture Transport Server. These are all security-sensitive components so they should be built and managed in accordance with best practices for security devices. This is especially important for the NEA Server and its components since a compromise of this device would affect the security and availability of the entire network (similar to compromise of a AAA server). Communications between the trusted parties must also be secured. For example, if the Posture Broker Server and the Posture Transport Server are separate components, their communications must be secured.
如上所述，任何受信任方的妥协或错误操作都是具有重大安全影响的严重问题。这包括姿态代理客户端、姿态代理服务器、姿态传输客户端和姿态传输服务器。这些都是安全敏感组件，因此应根据安全设备的最佳实践来构建和管理它们。这对于NEA服务器及其组件尤其重要，因为该设备的损坏会影响整个网络的安全性和可用性（类似于AAA服务器的损坏）。还必须保护受信任方之间的通信。例如，如果姿态代理服务器和姿态传输服务器是独立的组件，则必须保护它们的通信。
Since the NEA Client may be a mobile device with little physical security (such as a laptop computer or even a public telephone), it should generally be assumed that some proportion of Access NEA Clients will be compromised and therefore hostile. The NEA Server should be designed to be robust against hostile NEA Clients. Once a
由于NEA客户端可能是物理安全性很低的移动设备（例如笔记本电脑或甚至是公用电话），因此通常应假定一定比例的NEA客户端访问将受到威胁，因此具有敌意。NEA服务器的设计应确保能够抵御敌对的NEA客户端。每年一次
compromised NEA Client is detected, it can be treated in a manner equivalent to an untrusted party and should pose no greater threat than any other untrusted party.
如果检测到受损的NEA客户端，则可以采用与不受信任方等效的方式对其进行处理，并且不会造成比任何其他不受信任方更大的威胁。
Countermeasures against a compromised NEA Server (or a component thereof such as a Posture Broker Server or a Posture Transport Server) include prevention of compromise, detection of compromise, and mitigation of the effects of compromise. For prevention, the NEA Server and its components and dependencies should be implemented using secure implementation techniques (e.g., secure coding and minimization) and managed using secure practices (e.g., strong authentication and separation of duty). For detection, the behavior of the NEA Server should be monitored (e.g., via logging especially of remediation instructions, intrusion detection systems, and probes that impersonate a valid NEA Client and record NEA Server behavior) and any anomalies analyzed. For mitigation, NEA Clients should not blindly follow remediation instructions received from a trusted NEA Server. At least for patches and other dangerous actions, they should validate these actions (e.g., via user confirmation) before proceeding. It should not be possible to configure a NEA Client to trust all NEA Servers without proper authentication and authorization.
针对受损的NEA服务器（或其组件，例如姿态代理服务器或姿态传输服务器）的对策包括防止危害、检测危害和减轻危害的影响。为了预防，应使用安全实施技术（例如，安全编码和最小化）实施NEA服务器及其组件和依赖项，并使用安全实践（例如，强身份验证和职责分离）进行管理。对于检测，应监控NEA服务器的行为（例如，通过记录补救指令、入侵检测系统和模拟有效NEA客户端并记录NEA服务器行为的探测器），并分析任何异常情况。对于缓解措施，NEA客户端不应盲目遵循从受信任的NEA服务器收到的补救指示。至少对于补丁和其他危险操作，他们应该在继续之前验证这些操作（例如，通过用户确认）。如果没有适当的身份验证和授权，则不可能将NEA客户端配置为信任所有NEA服务器。
Four new IANA registries are defined by this specification: PB-TNC Message Types, PA Subtypes, PB-TNC Remediation Parameters Types, and PB-TNC Error Codes. This section explains how these registries work.
本规范定义了四个新的IANA注册表：PB-TNC消息类型、PA子类型、PB-TNC修复参数类型和PB-TNC错误代码。本节介绍这些注册表的工作原理。
All of these registries support IETF standard values and vendor-defined values. To explain this phenomenon, we will use the PB-TNC Message Type as an example but the other three registries work the same way. Whenever a PB-TNC Message Type appears on a network, it is always accompanied by an SMI Private Enterprise Number (PEN), also known as a vendor ID. If this vendor ID is zero, the accompanying PB-TNC Message Type is an IETF standard value listed in the IANA registry for PB-TNC Message Types and its meaning is defined in the specification listed for that PB-TNC Message Type in that registry. If the vendor ID is not zero, the meaning of the PB-TNC Message Type is defined by the vendor identified by the vendor ID (as listed in the IANA registry for SMI PENs). The identified vendor is encouraged but not required to register with IANA some or all of the PB-TNC Message Types used with their vendor ID and publish a specification for each of these values.
所有这些注册表都支持IETF标准值和供应商定义的值。为了解释这种现象，我们将以PB-TNC消息类型为例，但其他三个注册中心的工作方式相同。每当PB-TNC消息类型出现在网络上时，它总是伴随着SMI私有企业号（PEN），也称为供应商ID。如果此供应商ID为零，随附的PB-TNC消息类型是IANA注册表中针对PB-TNC消息类型列出的IETF标准值，其含义在该注册表中针对该PB-TNC消息类型列出的规范中定义。如果供应商ID不为零，则PB-TNC消息类型的含义由供应商ID标识的供应商定义（如IANA注册中心SMI PENs中所列）。鼓励已识别的供应商，但不要求其向IANA注册其供应商ID使用的部分或全部PB-TNC消息类型，并发布这些值的规范。
This delegation of namespace is analogous to the technique used for OIDs. It can result in interoperability problems if vendors require support for particular vendor-specific values. However, such
名称空间的这种委托类似于用于OID的技术。如果供应商需要支持特定于供应商的值，则可能会导致互操作性问题。但是,
behavior is explicitly prohibited by this specification, which dictates that "Posture Broker Clients and Posture Broker Servers MUST NOT require support for particular vendor-specific PB-TNC message types and MUST interoperate with other parties despite any differences in the set of vendor-specific PB-TNC message types supported (although they MAY permit administrators to configure them to require support for specific PB-TNC message types)." Similar requirements are included for PA Subtypes, Remediation Parameters Types, and PB-TNC Error Codes.
本规范明确禁止该行为，该规范规定“姿态代理客户端和姿态代理服务器不得要求支持特定于供应商的PB-TNC消息类型，并且必须与其他方互操作，尽管支持的特定于供应商的PB-TNC消息类型集存在任何差异（尽管它们可能允许管理员将其配置为需要特定PB-TNC消息类型的支持）。“PA子类型、修正参数类型和PB-TNC错误代码也包含类似的要求。
For all of the four IANA registries defined by this specification, new values are added to the registry by Expert Review with Specification Required, using the Designated Expert process defined in RFC 5226 [5].
对于本规范定义的所有四个IANA注册中心，使用RFC 5226[5]中定义的指定专家流程，通过专家评审将新值添加到注册中心，并符合规范要求。
This section provides guidance to designated experts so that they may make decisions using a philosophy appropriate for these registries.
本节为指定专家提供指导，以便他们可以使用适用于这些登记册的理念作出决定。
The registries defined in this document have plenty of values. In most cases, the IETF has approximately 2^32 values available for it to define and each vendor the same number of values for its use. The only exception is the registry for PB-TNC Error Codes where 2^16 values are available for the IETF and 2^16 values for each vendor. Because there are so many values available, designated experts should not be terribly concerned about exhausting the set of values.
本文档中定义的注册表有很多值。在大多数情况下，IETF大约有2^32个值可供其定义，每个供应商使用相同数量的值。唯一的例外是PB-TNC错误代码注册表，其中IETF有2^16个值，每个供应商有2^16个值。因为有这么多可用的值，指定的专家不应该非常担心耗尽这些值。
Instead, designated experts should focus on the following requirements. All values in these IANA registries MUST be documented in a specification that is permanently and publicly available. IETF standard values MUST also be useful, not harmful to the Internet, and defined in a manner that is clear and likely to ensure interoperability.
相反，指定专家应关注以下要求。这些IANA注册表中的所有值必须记录在永久公开的规范中。IETF标准值也必须是有用的，不会对互联网有害，并以明确的方式定义，以确保互操作性。
Designated experts should encourage vendors to avoid defining similar but incompatible values and instead agree on a single IETF standard value. 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 the IANA and authorize the 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对该副本进行存档，并在某个时候，如果文件不再通过其他渠道免费提供给所有人，则该副本将免费提供给所有人。
The name for this registry is "PB-TNC Message Types". Each entry in this registry should include a human-readable name, an SMI Private Enterprise Number, a decimal integer value between 0 and 2^32-2, and a reference to a specification where the contents of this message type are defined. This specification must define the meaning of this PB-TNC message type and the format and semantics of the PB-TNC Message Value field for PB-TNC messages that include the designated numeric value in the PB-TNC Message Type field and the designated Private Enterprise Number in the PB-TNC Vendor ID field.
此注册表的名称为“PB-TNC消息类型”。此注册表中的每个条目应包括一个可读名称、一个SMI私有企业编号、一个介于0和2^32-2之间的十进制整数值，以及对定义此消息类型内容的规范的引用。本规范必须定义该PB-TNC消息类型的含义以及PB-TNC消息的PB-TNC消息值字段的格式和语义，该字段包括PB-TNC消息类型字段中的指定数值和PB-TNC供应商ID字段中的指定私有企业编号。
Entries to this registry are added by Expert Review with Specification Required, following the guidelines in section 6.1.
根据第6.1节中的指南，通过专家评审添加此注册表的条目，并提供所需的规范。
The following entries for this registry are defined in this document. They are the initial entries in the registry for PB-TNC Message Types.
本文档中定义了此注册表的以下条目。它们是PB-TNC消息类型注册表中的初始条目。
PEN Integer Name Defining Specification
--- ------- ---- ----------------------
0 0 PB-Experimental RFC 5793
0 1 PB-PA RFC 5793
0 2 PB-Assessment-Result RFC 5793
0 3 PB-Access-Recommendation RFC 5793
0 4 PB-Remediation-Parameters RFC 5793
0 5 PB-Error RFC 5793
0 6 PB-Language-Preference RFC 5793
0 7 PB-Reason-String RFC 5793
0 0xffffffff Reserved RFC 5793
PEN Integer Name Defining Specification
--- ------- ---- ----------------------
0 0 PB-Experimental RFC 5793
0 1 PB-PA RFC 5793
0 2 PB-Assessment-Result RFC 5793
0 3 PB-Access-Recommendation RFC 5793
0 4 PB-Remediation-Parameters RFC 5793
0 5 PB-Error RFC 5793
0 6 PB-Language-Preference RFC 5793
0 7 PB-Reason-String RFC 5793
0 0xffffffff Reserved RFC 5793
The name for this registry is "PA Subtypes". Each entry in this registry should include a human-readable name, an SMI Private Enterprise Number, a decimal integer value between 0 and 2^32-2, and a reference to a specification where the contents of this PA subtype are defined. This specification must define the meaning of this PA subtype and the format and semantics of the PA Message Body field for PB-TNC messages that have a PB-TNC Vendor ID of 0, a PB-TNC Message Type of PB-PA, the designated numeric value in the PA Subtype field, and the designated Private Enterprise Number in the PA Message Vendor ID field.
此注册表的名称为“PA子类型”。此注册表中的每个条目应包括一个可读名称、一个SMI私有企业编号、一个介于0和2^32-2之间的十进制整数值，以及对定义此PA子类型内容的规范的引用。对于PB-TNC供应商ID为0、PB-TNC消息类型为PB-PA、PA子类型字段中的指定数值以及PA消息供应商ID字段中的指定私有企业编号的PB-TNC消息，本规范必须定义此PA子类型的含义以及PA消息正文字段的格式和语义。
Entries to this registry are added by Expert Review with Specification Required, following the guidelines in section 6.1.
根据第6.1节中的指南，通过专家评审添加此注册表的条目，并提供所需的规范。
This document does not define any initial entries for this registry. Therefore, this registry should initially be empty. Subsequent RFCs (such as PA-TNC) will define entries in this registry.
本文档未定义此注册表的任何初始项。因此，此注册表最初应为空。后续RFC（如PA-TNC）将在此注册表中定义条目。
The name for this registry is "PB-TNC Remediation Parameters Types". Each entry in this registry should include a human-readable name, an SMI Private Enterprise Number, a decimal integer value between 0 and 2^32-1, and a reference to a specification where the contents of this remediation parameters type are defined. This specification must define the meaning of this remediation parameters type value and the format and semantics of the Remediation Parameters field for PB-TNC messages that have a PB-TNC Vendor ID of 0, a PB-TNC Message Type of PB-Remediation-Parameters, the designated numeric value in the Remediation Parameters Type field, and the designated Private Enterprise Number in the Remediation Parameters Vendor ID field.
此注册表的名称为“PB-TNC修复参数类型”。此注册表中的每个条目都应包括一个可读名称、一个SMI私有企业编号、一个介于0和2^32-1之间的十进制整数值，以及对定义此修正参数类型内容的规范的引用。对于PB-TNC供应商ID为0、PB-TNC消息类型为PB补救参数、补救参数类型字段中的指定数值的PB-TNC消息，本规范必须定义此补救参数类型值的含义以及补救参数字段的格式和语义，以及补救参数供应商ID字段中指定的私人企业编号。
Entries to this registry are added by Expert Review with Specification Required, following the guidelines in section 6.1.
根据第6.1节中的指南，通过专家评审添加此注册表的条目，并提供所需的规范。
The following entries for this registry are defined in this document. They are the initial entries in the registry for PB-TNC Remediation Parameters Types.
本文档中定义了此注册表的以下条目。它们是PB-TNC修复参数类型注册表中的初始条目。
PEN Integer Name Defining Specification
--- ------- ---- ----------------------
0 1 Remediation-URI RFC 5793
0 2 Remediation-String RFC 5793
PEN Integer Name Defining Specification
--- ------- ---- ----------------------
0 1 Remediation-URI RFC 5793
0 2 Remediation-String RFC 5793
The name for this registry is "PB-TNC Error Codes". Each entry in this registry should include a human-readable name, an SMI Private Enterprise Number, a decimal integer value between 0 and 2^16-1, and a reference to a specification where this error code is defined. This specification must define the meaning of this error code and the format and semantics of the Error Parameters field for PB-TNC messages that have a PB-TNC Vendor ID of 0, a PB-TNC Message Type of PB-Error, the designated numeric value in the Error Code field, and the designated Private Enterprise Number in the Error Code Vendor ID field.
此注册表的名称为“PB-TNC错误代码”。此注册表中的每个条目应包括一个可读名称、一个SMI私有企业编号、一个介于0和2^16-1之间的十进制整数值，以及对定义此错误代码的规范的引用。对于PB-TNC供应商ID为0、PB-TNC消息类型为PB error、错误代码字段中的指定数值以及错误代码供应商ID字段中的指定私有企业编号的PB-TNC消息，本规范必须定义此错误代码的含义以及错误参数字段的格式和语义。
Entries to this registry are added by Expert Review with Specification Required, following the guidelines in section 6.1.
根据第6.1节中的指南，通过专家评审添加此注册表的条目，并提供所需的规范。
The following entries for this registry are defined in this document. They are the initial entries in the registry for PB-TNC Error Codes.
本文档中定义了此注册表的以下条目。它们是PB-TNC错误代码注册表中的初始条目。
PEN Integer Name Defining Specification
--- ------- ---- ----------------------
0 0 Unexpected Batch Type RFC 5793
0 1 Invalid Parameter RFC 5793
0 2 Local Error RFC 5793
0 3 Unsupported Mandatory Message RFC 5793
0 4 Version Not Supported RFC 5793
PEN Integer Name Defining Specification
--- ------- ---- ----------------------
0 0 Unexpected Batch Type RFC 5793
0 1 Invalid Parameter RFC 5793
0 2 Local Error RFC 5793
0 3 Unsupported Mandatory Message RFC 5793
0 4 Version Not Supported RFC 5793
Thanks to the Trusted Computing Group for contributing the initial text upon which this document was based.
感谢Trusted Computing Group提供了本文档所基于的初始文本。
The authors of this document would like to acknowledge the following people who have contributed to or provided substantial input on the preparation of this document or predecessors to it: Bernard Aboba, Amit Agarwal, Morteza Ansari, Diana Arroyo, Stuart Bailey, Boris Balacheff, Gene Chang, Roger Chickering, Scott Cochrane, Pasi Eronen, Aman Garg, Sandilya Garimella, Lauren Giroux, Mudit Goel, Charles Goldberg, Thomas Hardjono, Chris Hessing, Hidenobu Ito, John Jerrim, Meenakshi Kaushik, Greg Kazmierczak, Scott Kelly, Tom Kelnar, Bryan Kingsford, PJ Kirner, Houcheng Lee, Sung Lee, Lisa Lorenzin, Mahalingam Mani, Paul Mayfield, Michael McDaniels, Bipin Mistry, Rod Murchison, Barbara Nelson, Kazuaki Nimura, Ron Pon, Ivan Pulleyn, Alex Romanyuk, Chris Salter, Mauricio Sanchez, Paul Sangster, Dean Sheffield, Curtis Simonson, Jeff Six, Ned Smith, Michelle Sommerstad, Joseph Tardo, Lee Terrell, Chris Trytten, Brad Upson, Ram Vadali, Guha Prasad Venataraman, John Vollbrecht, Jun Wang, and Han Yin.
本文件的作者谨向以下人士表示感谢，他们为本文件或其前身的编写做出了贡献或提供了大量投入：伯纳德·阿博巴、阿米特·阿加瓦尔、莫特扎·安萨里、黛安娜·阿罗约、斯图亚特·贝利、鲍里斯·巴拉切夫、吉恩·张、罗杰·奇克林、斯科特·科克伦、帕西·埃隆、阿曼·加格、，Sandilya Garimella，Lauren Giroux，Mudit Goel，Charles Goldberg，Thomas Hardjono，Chris Hessing，Hidenobu Ito，John Jerrim，Meenakshi Kaushik，Greg Kazmierczak，Scott Kelly，Tom Kelnar，Bryan Kingsford，PJ Kirner，Houcheng Lee，Sung Lee，Lisa Lorenzin，Mahlingam Mani，Paul Mayfield，Michael McDaniels，Bipin Mistry，Rod Murchison，Barbara Nelson，卡祖基·尼穆拉、罗恩·庞、伊万·普莱恩、亚历克斯·罗曼纽克、克里斯·索尔特、毛里西奥·桑切斯、保罗·桑斯特、谢菲尔德院长、柯蒂斯·西蒙森、杰夫·六、内德·史密斯、米歇尔·索默斯塔德、约瑟夫·塔多、李·特雷尔、克里斯·特里滕、布拉德·厄普森、拉姆·瓦达利、古哈·普拉萨德·维纳拉曼、约翰·沃尔布雷希特、王军和韩茵。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[2] Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[3] Phillips, A., Ed., and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[3] Phillips，A.，Ed.，和M.Davis，Ed.，“识别语言的标签”，BCP 47，RFC 5646，2009年9月。
[4] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002.
[4] Alvestrand，H.，“内容语言标题”，RFC 3282，2002年5月。
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[5] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[6] Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[7] Hanna, S., Hurst, R. and R. Sahita, "TNC IF-TNCCS: TLV Binding", Trusted Computing Group, February 2008.
[7] Hanna，S.，Hurst，R.和R.Sahita，“TNC IF-TNCCS:TLV绑定”，可信计算集团，2008年2月。
[8] Sangster, P., Khosravi, H., Mani, M., Narayan, K., and J. Tardo, "Network Endpoint Assessment (NEA): Overview and Requirements", RFC 5209, June 2008.
[8] Sangster，P.，Khosravi，H.，Mani，M.，Narayan，K.，和J.Tardo，“网络端点评估（NEA）：概述和要求”，RFC 52092008年6月。
[9] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[9] Aboba，B.，Blunk，L.，Vollbrecht，J.，Carlson，J.，和H.Levkowetz，Ed.，“可扩展认证协议（EAP）”，RFC 37482004年6月。
[10] Sangster, P., and K. Narayan, "PA-TNC: A Posture Attribute (PA) Protocol Compatible with Trusted Network Connect (TNC)", RFC 5792, March 2010.
[10] Sangster，P.和K.Narayan，“PA-TNC：与可信网络连接（TNC）兼容的姿态属性（PA）协议”，RFC 57922010年3月。
This scenario involves the assessment of an endpoint initiated during network join. The assessment is triggered by the Posture Broker Client (PBC) and involves collection of patch information from both Standard Operating System (OS) Posture Collector and vendor-specific Patch Posture Collector (PC). The assessment by both the vendor-specific Patch Posture Validator (PV) and Standard OS Posture Validator result in a compliant assessment decision that results in a compliant System Assessment Decision to be returned by the Posture Broker Server (PBS).
此场景涉及对网络连接期间启动的端点的评估。评估由姿态代理客户端（PBC）触发，包括从标准操作系统（OS）姿态收集器和供应商特定的补丁姿态收集器（PC）收集补丁信息。特定于供应商的补丁姿态验证器（PV）和标准操作系统姿态验证器的评估都会产生符合要求的评估决策，从而导致姿态代理服务器（PBS）返回符合要求的系统评估决策。
+--------+ +-------+ +---------+ +--------+ +-------++--------+
+--------+ +-------+ +---------+ +--------+ +-------++--------+
| Vndr. X| | Std. | | Std. | | Std. | | Std. || Vndr. X|
| Vndr. X| | Std. | | Std. | | Std. | | Std. || Vndr. X|
|Patch PC| | OS PC | | PBC | | PBS | | OS PV ||Patch PV|
|Patch PC| | OS PC | | PBC | | PBS | | OS PV ||Patch PV|
+----+---+ +---+---+ +-----+---+ +---+----+ +---+----++---+---+
+----+---+ +---+---+ +-----+---+ +---+----+ +---+----++---+---+
| | N/W Join| | | |
| | N/W Join| | | |
| | ----->| | | |
| | ----->| | | |
| | Req Post. | | | |
| | Req Post. | | | |
| +<----------+ | | |
| +<----------+ | | |
| | Req Post. | | | |
| | Req Post. | | | |
+<--------------------| | | |
+<--------------------| | | |
|Vndr X Patch Posture | | | |
|Vndr X Patch Posture | | | |
|-------------------->| | | |
|-------------------->| | | |
| |OS Posture | | | |
| |OS Posture | | | |
| |---------->| | | |
| |---------->| | | |
| | | Posture | | |
| | | Posture | | |
| | | Report | | |
| | | Report | | |
| | +-------->| | |
| | +-------->| | |
| | | | Verify | |
| | | | Verify | |
| | | | Posture | |
| | | | Posture | |
| | | |---------> |
| | | |---------> |
| | | | | Verify |
| | | | | Verify |
| | | | | Posture |
| | | | | Posture |
| | | |------------------->|
| | | |------------------->|
| | | | OS Reslt | |
| | | | OS Reslt | |
| | | |<---------| |
| | | |<---------| |
| | | | VndrX Patch Result |
| | | | VndrX Patch Result |
| | | Assess |<-------------------|
| | | Assess |<-------------------|
| | | Result | |
| | | Result | |
| | <---------| | |
| | <---------| | |
| | OS PRslt | | | |
| | OS PRslt | | | |
| |<----------| | | |
| |<----------| | | |
| VndrX Patch PResult | | | |
| VndrX Patch PResult | | | |
|<--------------------| | | |
|<--------------------| | | |
This section shows the contents of the key fields in each of the PA messages exchanged in this use case. When necessary, additional commentary is provided to explain why certain fields contain the shown values. Note that many of the flows shown are between components on the same system so no message contents are shown.
本节显示了在本用例中交换的每个PA消息中的关键字段的内容。必要时，提供附加注释，解释某些字段包含显示值的原因。请注意，显示的许多流是在同一系统上的组件之间的，因此不显示任何消息内容。
This flow represents the event that causes the PBC to decide to start an assessment of the endpoint in order to gain access to the network. This is merely an event and doesn't include a message being sent.
此流表示导致PBC决定开始端点评估以获得网络访问权的事件。这只是一个事件，不包括正在发送的消息。
This flow illustrates an invocation of the OS and Patch Posture Collectors requesting particular posture attributes to be sent. Because this use case is triggered locally, NEA doesn't specify the contents of this flow.
此流程演示了对操作系统和补丁姿态收集器的调用，请求发送特定姿态属性。因为这个用例是在本地触发的，所以NEA没有指定这个流的内容。
This flow contains the PA message from the Vendor X Patch Posture Collector; the message content is described in the PA-TNC specification.
此流包含来自供应商X Patch姿态收集器的PA消息；PA-TNC规范中描述了消息内容。
This flow contains the PA message from the OS Posture Collector; the message content is described in the PA-TNC specification.
此流包含来自OS姿态采集器的PA消息；PA-TNC规范中描述了消息内容。
This flow contains the PB message containing the PA messages from the Patch and OS Posture Collectors:
此流包含PB消息，其中包含来自补丁和OS姿态采集器的PA消息：
PB Envelope {
PB信封{
HDR {
HDR{
D bit=0 (Posture Broker Client is originator)
D位=0（姿态代理客户端为发起人）
Batch Type=CDATA
批处理类型=CDATA
Batch Length
批次长度
}
}
PB Message 1 {
PB消息1{
Vendor-id=0
供应商id=0
Type =2 (PB-PA)
类型=2（PB-PA）
Length
长
Value = {
Value = {
PA-Msg-vendor-id=0 (Standard)
PA Msg供应商id=0（标准）
PA-subtype=1 (OS)
PA子类型=1（OS）
OS Posture PA Message
操作系统姿态PA消息
}
}
}
}
PB Message 2 {
PB消息2{
Vendor-id=0
供应商id=0
Type =2 (PB-PA)
类型=2（PB-PA）
Length
长
Value = {
Value = {
PA-Msg-vendor-id=1 (Vendor X)
PA Msg供应商id=1（供应商X）
PA-subtype=1 (Vendor X PA sub-type for patch management)
PA子类型=1（用于补丁管理的供应商X PA子类型）
Vendor X Patch Posture PA Message
供应商X补丁姿态PA消息
}
}
}
}
}
}
This flow illustrates an invocation of the OS and Patch Posture Validators requesting verification of the posture attributes received. Because this flow happens locally within the NEA server, NEA doesn't specify the message content.
此流程演示了对操作系统和补丁姿态验证器的调用，请求验证接收到的姿态属性。由于此流在NEA服务器中本地发生，因此NEA不指定消息内容。
This flow contains the PA message (Posture Assessment Result) from the OS Posture Validator; the message content is described in the PA-TNC specification.
此流包含来自OS姿态验证器的PA消息（姿态评估结果）；PA-TNC规范中描述了消息内容。
This flow contains the PA message (Posture Assessment Result) from the Vendor X Patch Posture Validator; the message content is described in the PA-TNC specification.
此流程包含来自供应商X Patch姿态验证器的PA消息（姿态评估结果）；PA-TNC规范中描述了消息内容。
This flow contains the PB message containing the system assessment result computed by the Posture Broker Server and the PA messages from the Patch and OS Posture Validators:
此流包含PB消息，其中包含由姿态代理服务器计算的系统评估结果，以及来自修补程序和OS姿态验证器的PA消息：
PB Envelope {
PB信封{
HDR {
HDR{
D bit=1 (Posture Broker Server is originator)
D位=1（姿态代理服务器是发起者）
Batch Type=RESULT
批次类型=结果
Batch Length
批次长度
}
}
PB Message 1 {
PB消息1{
Vendor-id=0,
供应商id=0，
Type =3 (Access-Recommendation)
类型=3（访问建议）
Length
长
Value = {
Value = {
System-Evaluation-Result=0 (Compliant)
系统评估结果=0（符合要求）
}
}
}
}
PB Message 2 {
PB消息2{
Vendor-id=0,
供应商id=0，
Type=2 (PB-PA)
类型=2（PB-PA）
Length
长
Value = {
Value = {
PA-Msg-vendor-id=0
PA Msg供应商id=0
PA-subtype=1 (OS)
PA子类型=1（OS）
OS Posture Result PA Message
操作系统姿态结果PA消息
}
}
}
}
PB Message 3 {
PB消息3{
Vendor-id=0,
供应商id=0，
Type=2 (PB-PA)
类型=2（PB-PA）
Length
长
Value = {
Value = {
PA-Msg-vendor-id=1 (Vendor X)
PA Msg供应商id=1（供应商X）
PA-subtype=1 (Vendor X PA sub-type for patch management)
PA子类型=1（用于补丁管理的供应商X PA子类型）
Vendor X Patch Posture Result PA Message
供应商X补丁姿态结果PA消息
}
}
}
}
}
}
These flows illustrate an invocation of the OS and Vendor X Patch Posture Collectors to receive the posture assessment results. Because this flow is triggered locally, NEA doesn't specify the contents of this flow.
这些流程说明了如何调用OS和供应商X补丁姿态采集器来接收姿态评估结果。因为此流是本地触发的，所以NEA不指定此流的内容。
This scenario involves the assessment of an endpoint initiated by the NEA server. The assessment is triggered by the Posture Broker Server and involves collection of Anti-Virus attributes for two Anti-Virus components running on the endpoint. The endpoint is assessed to be compliant by one of the vendor (Vendor X) anti-virus posture validators and non-compliant by the other vendor (Vendor Y) anti-virus posture validator. This results in a non-compliant System Assessment Decision to be returned by the Posture Broker Server. The Posture Broker Server also returns remediation instructions for the endpoint as part of the response.
此场景涉及对NEA服务器启动的端点的评估。该评估由姿态代理服务器触发，包括收集端点上运行的两个防病毒组件的防病毒属性。端点由一个供应商（供应商X）防病毒姿态验证器评估为符合，而由另一个供应商（供应商Y）防病毒姿态验证器评估为不符合。这将导致姿态代理服务器返回不符合要求的系统评估决策。姿态代理服务器还返回端点的修正指令，作为响应的一部分。
+--------+ +-------+ +---------+ +--------+ +-------+ +--------+
+--------+ +-------+ +---------+ +--------+ +-------+ +--------+
| Vndr Y | | Vndr X| | Std. | | Std. | | Vndr X| | Vndr Y |
| Vndr Y | | Vndr X| | Std. | | Std. | | Vndr X| | Vndr Y |
| AV PC | | AV PC | | PBC | | PBS | | AV PV | | AV PV |
| AV PC | | AV PC | | PBC | | PBS | | AV PV | | AV PV |
+----+---+ +---+---+ +-----+---+ +---+----+ +---+---+ +----+---+
+----+---+ +---+---+ +-----+---+ +---+----+ +---+---+ +----+---+
| | | N/W Join| | |
| | | N/W Join| | |
| | | ----->| | |
| | | ----->| | |
| | | | Create | |
| | | | Create | |
| | | |Post. Req | |
| | | |Post. Req | |
| | | |--------->| |
| | | |--------->| |
| | | |Create Posture Req |
| | | |Create Posture Req |
| | | |----------+--------->|
| | | |----------+--------->|
| | | |Vndr Y AV Posture Req|
| | | |Vndr Y AV Posture Req|
| | | |<---------+----------|
| | | |<---------+----------|
| | | |Vndr X AV | |
| | | |Vndr X AV | |
| | | |Post. Req | |
| | | |Post. Req | |
| | | Posture |<---------| |
| | | Posture |<---------| |
| | | Request | | |
| | | Request | | |
| | Vndr X AV |<--------| | |
| | Vndr X AV |<--------| | |
| | Post. Req | | | |
| | Post. Req | | | |
| |<----------| | | |
| |<----------| | | |
| Vndr Y AV | | | |
| Vndr Y AV | | | |
| Posture Req | | | |
| Posture Req | | | |
+<---------+-----------| | | |
+<---------+-----------| | | |
| Vndr Y AV Posture | | | |
| Vndr Y AV Posture | | | |
+----------+---------->| | | |
+----------+---------->| | | |
| | Vndr X AV | | | |
| | Vndr X AV | | | |
| | Posture | | | |
| | Posture | | | |
| |---------->| Posture | | |
| |---------->| Posture | | |
| | |Response | | |
| | |Response | | |
| | |-------->| | |
| | |-------->| | |
| | | | Verify | |
| | | | Verify | |
| | | | Posture | |
| | | | Posture | |
| | | |--------->| |
| | | |--------->| |
| | | | Verify Posture |
| | | | Verify Posture |
| | | |----------+--------->|
| | | |----------+--------->|
| | | |Vndr Y Posture Result|
| | | |Vndr Y Posture Result|
| | | |<---------+----------|
| | | |<---------+----------|
| | | |Vndr X AV | |
| | | |Vndr X AV | |
| | | |Post Reslt| |
| | | |Post Reslt| |
| | | Assess |<---------| |
| | | Assess |<---------| |
| | | Result | | |
| | | Result | | |
| | Vndr X AV |<--------| | |
| | Vndr X AV |<--------| | |
| |Post Reslt |<--------| | |
| |Post Reslt |<--------| | |
| |<----------| | | |
| |<----------| | | |
| Vndr Y AV Post Reslt | | | |
| Vndr Y AV Post Reslt | | | |
+<---------+-----------| | | |
+<---------+-----------| | | |
| | | | | |
| | | | | |
This section shows the contents of the key fields in each of the PA messages exchanged in this use case. When necessary, additional commentary is provided to explain why certain fields contain the shown values. Note that many of the flows shown are between components on the same system so no message contents are shown.
本节显示了在本用例中交换的每个PA消息中的关键字段的内容。必要时，提供附加注释，解释某些字段包含显示值的原因。请注意，显示的许多流是在同一系统上的组件之间的，因此不显示任何消息内容。
This flow represents the event that causes the PBS to decide to start an assessment of the endpoint in order to gain access to the network. This is merely an event and doesn't include a message being sent.
此流表示导致PBS决定开始端点评估以获得网络访问权的事件。这只是一个事件，不包括正在发送的消息。
This flow illustrates an invocation of the Vendor X and Vendor Y Anti-Virus posture validators requesting posture requests to be created. Because this use case is triggered locally, NEA doesn't specify the contents of this flow.
此流程演示了对供应商X和供应商Y反病毒姿态验证器的调用，请求创建姿态请求。因为这个用例是在本地触发的，所以NEA没有指定这个流的内容。
This flow contains the PA message (Posture Request) from the Vendor X Anti-Virus Posture Validator; the message content is described in the PA-TNC specification.
此流包含来自供应商X防病毒姿态验证程序的PA消息（姿态请求）；PA-TNC规范中描述了消息内容。
This flow contains the PA message (Posture Request) from the Vendor Y Anti-Virus Posture Validator; the message content is described in the PA-TNC specification.
此流包含来自供应商Y防病毒姿态验证器的PA消息（姿态请求）；PA-TNC规范中描述了消息内容。
This flow contains the PB message containing the PA messages from the Vendor X and Vendor Y Anti-Virus Posture Validators:
此流包含PB消息，其中包含来自供应商X和供应商Y防病毒验证程序的PA消息：
PB Envelope {
PB信封{
HDR {
HDR{
D bit=1 (Posture Broker Server is originator)
D位=1（姿态代理服务器是发起者）
Batch Type=SDATA
批次类型=SDATA
Batch Length
批次长度
}
}
PB Message 1 {
PB消息1{
Vendor-id=0
供应商id=0
Type =2 (PB-PA)
类型=2（PB-PA）
Length
长
Value = {
Value = {
PA-Msg-vendor-id=1 (Vendor X)
PA Msg供应商id=1（供应商X）
PA-subtype=2 (Vendor X PA sub-type for Anti-Virus)
PA子类型=2（供应商X防病毒PA子类型）
Vendor X AV Posture Request PA Message
供应商X AV姿态请求PA消息
}
}
}
}
PB Message 2 {
PB消息2{
Vendor-id=0
供应商id=0
Type =2 (PB-PA)
类型=2（PB-PA）
Length
长
Value = {
Value = {
PA-Msg-vendor-id=2 (Vendor Y)
PA消息供应商id=2（供应商Y）
PA-subtype=1 (Vendor Y PA sub-type for Anti-Virus)
PA子类型=1（供应商Y防病毒PA子类型）
Vendor Y AV Posture Request PA Message
供应商Y AV姿态请求PA消息
}
}
}
}
}
}
A.2.1.6. Process Posture Request (Vndr X AV Post Req & Vndr Y AV Posture Req)
A.2.1.6. 过程姿态请求（Vndr X AV Post请求和Vndr Y AV姿态请求）
This flow illustrates an invocation of the Vendor X and Vendor Y Anti-Virus Posture Collectors to process the Posture Request and return particular posture attributes requested. Because this use case is triggered locally, NEA doesn't specify the contents of this flow.
此流程说明了如何调用供应商X和供应商Y防病毒姿态收集器来处理姿态请求并返回请求的特定姿态属性。因为这个用例是在本地触发的，所以NEA没有指定这个流的内容。
This flow contains the PA message (response to the Posture Request) from the Vendor Y Anti-Virus Posture Collector; the message content is described in the PA-TNC specification.
此流包含来自供应商Y防病毒姿态收集器的PA消息（对姿态请求的响应）；PA-TNC规范中描述了消息内容。
This flow contains the PA message (response to the Posture Request) from the Vendor X Anti-Virus Posture Collector; the message content is described in the PA-TNC specification.
此流包含来自供应商X防病毒姿态收集器的PA消息（对姿态请求的响应）；PA-TNC规范中描述了消息内容。
This flow contains the PB message containing the PA messages from the Vendor X and Vendor Y Anti-Virus Posture Collectors:
此流包含PB消息，其中包含来自供应商X和供应商Y防病毒收集器的PA消息：
PB Envelope {
PB信封{
HDR {
HDR{
D bit=0 (Posture Broker Client is originator)
D位=0（姿态代理客户端为发起人）
Batch Type=CDATA
批处理类型=CDATA
Batch Length
批次长度
}
}
PB Message 1 {
PB消息1{
Vendor-id=0
供应商id=0
Type =2 (PB-PA)
类型=2（PB-PA）
Length
长
Value = {
Value = {
PA-Msg-vendor-id=1 (Vendor X)
PA Msg供应商id=1（供应商X）
PA-subtype=2 (Vendor X PA sub-type for Anti-Virus)
PA子类型=2（供应商X防病毒PA子类型）
Vendor X AV Posture PA Message
供应商X AV姿态PA消息
}
}
}
}
PB Message 2 {
PB消息2{
Vendor-id=0
供应商id=0
Type =2 (PB-PA)
类型=2（PB-PA）
Length
长
Value = {
Value = {
PA-Msg-vendor-id=2 (Vendor Y)
PA消息供应商id=2（供应商Y）
PA-subtype=1 (Vendor Y PA sub-type for Anti-Virus)
PA子类型=1（供应商Y防病毒PA子类型）
Vendor Y AV Posture PA Message
供应商Y AV姿态PA消息
}
}
}
}
}
}
This flow illustrates an invocation of the Vendor X and Vendor Y Anti-Virus Posture Validators requesting verification of the posture attributes received. Because this flow happens locally within the NEA server, NEA doesn't specify the message contents.
此流程演示了调用供应商X和供应商Y反病毒姿态验证器，请求验证收到的姿态属性。由于此流在NEA服务器中本地发生，因此NEA不指定消息内容。
This flow contains the PA message (Posture Assessment Result) from the Vendor Y Anti-Virus Posture Validator; the message content is described in the PA-TNC specification.
此流包含来自供应商Y防病毒姿态验证器的PA消息（姿态评估结果）；PA-TNC规范中描述了消息内容。
This flow contains the PA message (Posture Assessment Result) from the Vendor X Anti-Virus Posture Validator; the message content is described in the PA-TNC specification.
此流包含来自供应商X防病毒姿态验证器的PA消息（姿态评估结果）；PA-TNC规范中描述了消息内容。
This flow contains the PB message containing the system assessment result computed by the Posture Broker Server and the PA messages from the Patch and OS Posture Validators:
此流包含PB消息，其中包含由姿态代理服务器计算的系统评估结果，以及来自修补程序和OS姿态验证器的PA消息：
PB Envelope {
PB信封{
HDR {
HDR{
D bit=1 (Posture Broker Server is originator)
D位=1（姿态代理服务器是发起者）
Batch Type=RESULT
批次类型=结果
Batch Length
批次长度
}
}
PB Message 1 {
PB消息1{
Vendor-id=0,
供应商id=0，
Type=3 (Access-Recommendation)
类型=3（访问建议）
Length
长
Value = {
Value = {
PB-Assessment-Result=1 (Non-Compliant)
PB评估结果=1（不符合）
}
}
}
}
PB Message 2 {
PB消息2{
Vendor-id=0,
供应商id=0，
Type=4 (Remediation-Parameters)
Type=4 (Remediation-Parameters)translate error, please retry
Length
长
Value = {
Value = {
Remediation-Param-Vendor-ID=0
修正参数供应商ID=0
Remediation-Param-Type=1 (Remediation-URI)
修正参数类型=1（修正URI）
Remediation-Param=''http://xyz''
Remediation-Param=''http://xyz''
}
}
}
}
PB Message 3 {
PB消息3{
Vendor-id=0,
供应商id=0，
Type=4 (Remediation-Parameters)
类型=4（修正参数）
Length
长
Value = {
Value = {
Remediation-Param-Vendor-ID=0
修正参数供应商ID=0
Remediation-Param-Type=2 (Remediation-String)
修正参数类型=2（修正字符串）
Remediation-Param=''Try Step1, Step2,...''
修正参数=''尝试步骤1，步骤2，''
}
}
}
}
PB Message 4 {
PB消息4{
Vendor-id=0,
供应商id=0，
Type=2 (PB-PA)
类型=2（PB-PA）
Length
长
Value = {
Value = {
PA-Msg-vendor-id=1 (Vendor X)
PA Msg供应商id=1（供应商X）
PA-subtype=2 (Vendor X PA sub-type for Anti-Virus)
PA子类型=2（供应商X防病毒PA子类型）
Vendor X AV Posture Result PA Message
供应商X AV姿态结果PA消息
}
}
}
}
PB Message 5 {
PB消息5{
Vendor-id=0,
供应商id=0，
Type=2 (PB-PA)
类型=2（PB-PA）
Length
长
Value = {
Value = {
PA-Msg-vendor-id=2 (Vendor Y)
PA消息供应商id=2（供应商Y）
PA-subtype=1 (Vendor Y PA sub-type for Anti-Virus)
PA子类型=1（供应商Y防病毒PA子类型）
Vendor Y AV Posture Result PA Message
供应商Y AV姿态结果PA消息
}
}
}
}
}
}
These flows illustrate an invocation of the Vendor X and Vendor Y Anti-Virus Posture Collectors to receive the posture assessment results. Because this flow is triggered locally, NEA doesn't specify the contents of this flow.
这些流说明调用供应商X和供应商Y防病毒姿态收集器以接收姿态评估结果。因为此流是本地触发的，所以NEA不指定此流的内容。
This scenario involves the reassessment of an endpoint as a result of enabling a software component on the endpoint. The endpoint has two VPN client software components, one from vendor X for the user's home network and other from vendor Y for the network that the endpoint is currently accessing. The assessment is triggered when the user tries to use the Vendor X VPN client; this is a violation of the posture policy. The Posture Broker Client triggers the posture assessment when it receives a notification from the Standard VPN Posture Collector about the change to the operational state of the VPN component on the endpoint. Note that the VPN Posture Collector supports standard attributes and some vendor-defined attributes from vendor X's and vendor Y's namespaces. This use case doesn't leverage vendor-defined attributes. The assessment involves verification of
此场景涉及在端点上启用软件组件后对端点进行重新评估。端点有两个VPN客户端软件组件，一个来自供应商X，用于用户的家庭网络，另一个来自供应商Y，用于端点当前正在访问的网络。当用户尝试使用供应商X VPN客户端时触发评估；这违反了姿态政策。姿态代理客户端在收到来自标准VPN姿态收集器的关于端点上VPN组件的操作状态更改的通知时触发姿态评估。请注意，VPN姿态收集器支持标准属性以及来自供应商X和供应商Y名称空间的一些供应商定义的属性。此用例不利用供应商定义的属性。评估涉及对以下各项的核查：
the standard VPN posture attributes by the Standard VPN Posture Validator that results in a non-compliant assessment result. This use case relies on the use of a virtual Posture Collector concept described in section 3.3 of the PA-TNC specification. As illustrated in this example, the Posture Broker Client will assign two Posture Collector IDs to a single Posture Collector (Standard VPN PC), and the Posture Collector will generate two separate PA messages to report the posture for Vendor X and Vendor Y VPN Clients. The Posture Broker Client will use the assigned IDs in the PB message sent to the NEA Server. This entire behavior will be completely opaque to the NEA Server, which will handle the PB message as if there were two VPN Posture Collectors on the NEA Client.
标准VPN姿态验证器生成的标准VPN姿态属性会导致不符合要求的评估结果。该用例依赖于PA-TNC规范第3.3节中描述的虚拟姿态收集器概念的使用。如本例所示，姿态代理客户端将向单个姿态采集器（标准VPN PC）分配两个姿态采集器ID，姿态采集器将生成两条单独的PA消息，以报告供应商X和供应商Y VPN客户端的姿态。姿态代理客户端将使用发送到NEA服务器的PB消息中分配的ID。整个行为对NEA服务器来说是完全不透明的，NEA服务器将处理PB消息，就像NEA客户端上有两个VPN姿态采集器一样。
+--------+ +-------+ +---------+ +--------+ +--------+ +--------+
+--------+ +-------+ +---------+ +--------+ +--------+ +--------+
|Vndr X | |Vndr Y | |Standard | |Standard| |Standard| |Standard|
|Vndr X | |Vndr Y | |Standard | |Standard| |Standard| |Standard|
|VPNClnt | |VPNClnt| | VPN PC | | PBC | | PBS | | VPN PV |
|VPNClnt | |VPNClnt| | VPN PC | | PBC | | PBS | | VPN PV |
+----+---+ +---+---+ +-----+---+ +---+----+ +---+----+ +----+---+
Enble| | | | | |
+----+---+ +---+---+ +-----+---+ +---+----+ +---+----+ +----+---+
Enble| | | | | |
---->| | | | | |
---->| | | | | |
| VPN Status Change | | | |
| VPN Status Change | | | |
|--------------------->| Posture | | |
|--------------------->| Posture | | |
| | | Change | | |
| | | Change | | |
| | |-------->| | |
| | |-------->| | |
| | |Req. Post| | |
| | |Req. Post| | |
| | |<--------| | |
| | |<--------| | |
| |Ins/Rq Info| | | |
| |Ins/Rq Info| | | |
| |<----------| | | |
| |<----------| | | |
| Inspect/Request Info | | | |
| Inspect/Request Info | | | |
|<---------+-----------|VPNX Post| | |
|<---------+-----------|VPNX Post| | |
| | |-------->| | |
| | |-------->| | |
| | |VPNY Post| | |
| | |VPNY Post| | |
| | |-------->| | |
| | |-------->| | |
| | | | Posture | |
| | | | Posture | |
| | | | Report | |
| | | | Report | |
| | | |--------->| |
| | | |--------->| |
| | | | |Vrfy Post. |
| | | | |Vrfy Post. |
| | | | |---------->|
| | | | |---------->|
| | | | |VPN PRslt |
| | | | |VPN PRslt |
| | | | Assess |<----------|
| | | | Assess |<----------|
| | | | Result | |
| | | | Result | |
| | | |<---------| |
| | | |<---------| |
| | |VPN PRslt| | |
| | |VPN PRslt| | |
| | |<--------| | |
| | |<--------| | |
This section shows the contents of the key fields in each of the PA messages exchanged in this use case. When necessary, additional commentary is provided to explain why certain fields contain the shown values. Note that many of the flows shown are between components on the same system so no message contents are shown.
本节显示了在本用例中交换的每个PA消息中的关键字段的内容。必要时，提供附加注释，解释某些字段包含显示值的原因。请注意，显示的许多流是在同一系统上的组件之间的，因此不显示任何消息内容。
This flow represents the end user triggered event of starting the VPN Client software from Vendor X. This is merely an event and doesn't include a message being sent.
此流表示从供应商X启动VPN客户端软件的最终用户触发事件。这只是一个事件，不包括正在发送的消息。
This flow represents the detection of the active state of the Vendor X VPN Client software by the Standard VPN Posture Collector. This is merely an event and doesn't include a message being sent.
此流表示标准VPN姿态采集器检测供应商X VPN客户端软件的活动状态。这只是一个事件，不包括正在发送的消息。
This flow represents the notification of the VPN Posture change sent from the VPN Posture Collector to the Standard Posture Broker Client. This is merely an event and doesn't include a message being sent.
此流表示从VPN姿态收集器发送到标准姿态代理客户端的VPN姿态更改通知。这只是一个事件，不包括正在发送的消息。
This flow illustrates an invocation of the VPN Posture Collector requesting particular posture attributes to be sent. Because this use case is triggered locally, the contents of this flow aren't specified by NEA.
此流程说明了VPN姿态收集器的调用，请求发送特定姿态属性。因为这个用例是在本地触发的，所以NEA没有指定这个流的内容。
This flow illustrates the acquisition of the posture attributes by the Standard VPN Posture Collector from the Vendor X and Vendor Y VPN Client components. Because this flow is triggered locally, NEA doesn't specify the message contents.
此流程说明了标准VPN姿态采集器从供应商X和供应商Y VPN客户端组件获取姿态属性的过程。由于此流是在本地触发的，因此NEA不指定消息内容。
This flow contains the PA message from the VPN Posture Collector for Vendor X VPN Client posture; the message content is described in the PA-TNC specification.
此流包含来自供应商X VPN客户端姿态的VPN姿态收集器的PA消息；PA-TNC规范中描述了消息内容。
This flow contains the PA message from the VPN Posture Collector for Vendor Y VPN Client posture; the message content is described in the PA-TNC specification.
此流包含来自供应商Y VPN客户端姿态的VPN姿态收集器的PA消息；PA-TNC规范中描述了消息内容。
This flow contains the PB message containing the PA message from the VPN Posture Collector:
此流包含包含来自VPN姿态收集器的PA消息的PB消息：
PB Envelope {
PB信封{
HDR {
HDR{
D bit=0 (Posture Broker Client is originator)
D位=0（姿态代理客户端为发起人）
Batch Type=CRETRY
批次类型=CRETRY
Batch Length
批次长度
}
}
PB Message 1 {
PB消息1{
Vendor-id=0
供应商id=0
Type =2 (PB-PA)
类型=2（PB-PA）
Length
长
Value = {
Value = {
PA-Msg-vendor-id=0
PA Msg供应商id=0
PA-subtype=7 (VPN)
PA子类型=7（VPN）
Posture-Collector-ID=1 //Virtual Posture Collector ID for Vendor X VPN Client
姿态收集器ID=1//供应商X VPN客户端的虚拟姿态收集器ID
Vendor X VPN Posture PA Message
供应商X VPN姿态PA消息
}
}
}
}
PB Message 2 {
PB消息2{
Vendor-id=0
供应商id=0
Type =2 (PB-PA)
类型=2（PB-PA）
Length
长
Value = {
Value = {
PA-Msg-vendor-id=0
PA Msg供应商id=0
PA-subtype=7 (VPN)
PA子类型=7（VPN）
Posture-Collector-ID=2 //Virtual Posture Collector ID for Vendor Y VPN Client
姿态收集器ID=2//供应商Y VPN客户端的虚拟姿态收集器ID
Vendor Y VPN Posture PA Message
供应商Y VPN姿态PA消息
}
}
}
}
This flow illustrates an invocation of the VPN Posture Validator requesting verification of the posture attributes received. Because this flow happens locally within the NEA server, NEA doesn't specify the message contents.
此流程说明了VPN姿态验证程序的调用，请求验证接收到的姿态属性。由于此流在NEA服务器中本地发生，因此NEA不指定消息内容。
This flow contains the PA message (Posture Assessment Result) from the VPN Posture Validator; the message content is described in the PA-TNC specification.
此流包含来自VPN姿态验证器的PA消息（姿态评估结果）；PA-TNC规范中描述了消息内容。
This flow contains the PB message containing the system assessment result computed by the Posture Broker Server and the PA messages from the VPN Posture Validator:
此流包含包含由姿态代理服务器计算的系统评估结果的PB消息和来自VPN姿态验证程序的PA消息：
PB Envelope {
PB信封{
HDR {
HDR{
D bit=1 (Posture Broker Server is originator)
D位=1（姿态代理服务器是发起者）
Batch Type=RESULT
批次类型=结果
Batch Length
批次长度
}
}
PB Message 1 {
PB消息1{
Vendor-id=0,
供应商id=0，
Type =3 (Access-Recommendation)
类型=3（访问建议）
Length
长
Value = {
Value = {
PB-Assessment-Result=1 (Non-Compliant)
PB评估结果=1（不符合）
}
}
}
}
PB Message 2 {
PB消息2{
Vendor-id=0,
供应商id=0，
Type=2 (PB-PA)
类型=2（PB-PA）
Length
长
Value = {
Value = {
PA-Msg-vendor-id=0
PA Msg供应商id=0
PA-subtype=7 (VPN)
PA子类型=7（VPN）
VPN Posture Result PA Message
VPN姿态结果PA消息
}
}
}
}
This flow illustrate an invocation of the VPN Posture Collectors to receive the posture assessment result. Because this flow is triggered locally, NEA doesn't specify the contents of this flow.
此流程演示了VPN姿态采集器的调用，以接收姿态评估结果。因为此流是本地触发的，所以NEA不指定此流的内容。
This section evaluates the PB-TNC protocol against the requirements defined in the NEA Requirements document. Each subsection considers a separate requirement from the NEA Requirements document. Only common requirements (C-1 through C-11) and PB requirements (PB-1 through PB-6) are considered, since these are the only ones that apply to PB.
本节根据NEA要求文件中定义的要求评估PB-TNC协议。每一小节都考虑了NEA要求文件中的单独要求。仅考虑通用要求（C-1至C-11）和PB要求（PB-1至PB-6），因为它们是适用于PB的唯一要求。
Requirement C-1 says:
要求C-1规定：
C-1 NEA protocols MUST support multiple round trips between the NEA Client and NEA Server in a single assessment.
C-1 NEA协议必须在一次评估中支持NEA客户端和NEA服务器之间的多次往返。
PB-TNC meets this requirement. It allows an unlimited number of round trips between the NEA Client and NEA Server.
PB-TNC符合这一要求。它允许NEA客户端和NEA服务器之间进行无限次的往返。
Requirement C-2 says:
要求C-2规定：
C-2 NEA protocols SHOULD provide a way for both the NEA Client and the NEA Server to initiate a posture assessment or reassessment as needed.
C-2 NEA协议应为NEA客户端和NEA服务器提供一种方式，以便根据需要启动姿势评估或重新评估。
PB-TNC meets this requirement. Either the NEA Client or the NEA Server can initiate a posture assessment or reassessment.
PB-TNC符合这一要求。NEA客户端或NEA服务器均可启动姿势评估或重新评估。
There is one limitation on this support. If a NEA Server wishes to initiate a reassessment after it has sent a RESULT batch, it must close the underlying transport session and initiate a new assessment. For half-duplex transports, this is unavoidable unless a constant exchange of messages is maintained, which would be very wasteful. For full-duplex transports, it would be possible to allow the Posture Broker Server to send an SRETRY batch even in the Decided state. If the NEA working group reaches consensus that this change should be made, it will be.
这种支持有一个限制。如果NEA服务器希望在发送结果批处理后启动重新评估，则必须关闭基础传输会话并启动新评估。对于半双工传输，这是不可避免的，除非保持消息的持续交换，这将是非常浪费的。对于全双工传输，即使在已决定的状态下，也可以允许姿态代理服务器发送SRETRY批处理。如果NEA工作组达成一致意见，认为应该做出这一改变，那么它将是正确的。
Requirement C-3 says:
要求C-3规定：
C-3 NEA protocols including security capabilities MUST be capable of protecting against active and passive attacks by intermediaries and endpoints including prevention from replay-based attacks.
C-3 NEA协议（包括安全功能）必须能够防止中介和端点的主动和被动攻击，包括防止基于重播的攻击。
PB-TNC does not include any security capabilities. It depends on PT to supply a secure transport. This addresses all the necessary threats without adding an extra layer of security. Since this requirement only applies to NEA protocols that include security capabilities, PB-TNC meets this requirement.
PB-TNC不包括任何安全功能。这取决于PT提供的安全传输。这在不增加额外安全层的情况下解决了所有必要的威胁。由于此要求仅适用于包含安全功能的NEA协议，PB-TNC满足此要求。
Requirement C-4 says:
要求C-4规定：
C-4 The PA and PB protocols MUST be capable of operating over any PT protocol. For example, the PB protocol must provide a transport-independent interface allowing the PA protocol to operate without change across a variety of network protocol environments (e.g., EAP/802.1X, PANA, TLS, and IKE/IPsec).
C-4 PA和PB协议必须能够在任何PT协议上运行。例如，PB协议必须提供一个独立于传输的接口，允许PA协议在各种网络协议环境（例如EAP/802.1X、PANA、TLS和IKE/IPsec）中运行而无需更改。
PB-TNC meets this requirement. PB-TNC can operate over any PT protocol that meets the requirements for PT stated in the NEA Requirements document. Also, PB-TNC insulates the PA protocol from any specifics of the PT protocol. With PB-TNC, all PT protocols are equivalent from the perspective of the PA protocol.
PB-TNC符合这一要求。PB-TNC可在满足NEA要求文件中规定的PT要求的任何PT协议上运行。此外，PB-TNC将PA协议与PT协议的任何细节隔离。对于PB-TNC，从PA协议的角度来看，所有PT协议都是等效的。
Requirement C-5 says:
要求C-5规定：
C-5 The selection process for NEA protocols MUST evaluate and prefer the reuse of existing open standards that meet the requirements before defining new ones. The goal of NEA is not to create additional alternative protocols where acceptable solutions already exist.
C-5在定义新的开放标准之前，NEA协议的选择过程必须评估并优先重用满足要求的现有开放标准。NEA的目标不是在已经存在可接受解决方案的情况下创建其他替代协议。
Based on this requirement, PB-TNC should receive a strong preference. PB-TNC is equivalent with IF-TNCCS 2.0, an open TCG specification. IF-TNCCS 2.0 is an extension of the existing IF-TNCCS 1.X protocols, which have been implemented by dozens of vendors and open source projects.
基于这一要求，PB-TNC应受到强烈的青睐。PB-TNC等同于IF-TNCCS 2.0，一种开放式TCG规范。IF-TNCCS 2.0是现有IF-TNCCS 1.X协议的扩展，已有数十家供应商和开源项目实施了该协议。
Requirement C-6 says:
要求C-6规定：
C-6 NEA protocols MUST be highly scalable; the protocols MUST support many Posture Collectors on a large number of NEA Clients to be assessed by numerous Posture Validators residing on multiple NEA Servers.
C-6 NEA协议必须具有高度可扩展性；协议必须支持大量NEA客户端上的多个姿态采集器，这些客户端将由驻留在多个NEA服务器上的多个姿态验证器进行评估。
PB-TNC meets this requirement. PB-TNC supports up to 2^16-1 Posture Collectors and an equal number of Posture Validators in a given PB-TNC session. It also supports an unlimited number of NEA Clients and NEA Servers.
PB-TNC符合这一要求。PB-TNC在给定的PB-TNC会话中支持多达2^16-1个姿势收集器和相同数量的姿势验证器。它还支持无限数量的NEA客户端和NEA服务器。
The scalability of PB-TNC extends into other areas as well. For example, PB-TNC supports an unlimited number of batches and each batch can contain up to 2^32-1 octets and about 2^24 PA messages. Each PA message can contain up to 2^32-1 octets. Of course, sending this much data in a NEA assessment is not generally advisable, but the point is that PB-TNC is highly scalable.
PB-TNC的可扩展性也扩展到了其他领域。例如，PB-TNC支持无限数量的批次，每个批次最多可以包含2^32-1个八位字节和大约2^24个PA消息。每个PA消息最多可包含2^32-1个八位字节。当然，在NEA评估中发送这么多数据通常是不可取的，但关键是PB-TNC具有高度可扩展性。
Requirement C-7 says:
要求C-7规定：
C-7 The protocols MUST support efficient transport of a large number of attribute messages between the NEA Client and the NEA Server.
C-7协议必须支持在NEA客户端和NEA服务器之间高效传输大量属性消息。
PB-TNC meets this requirement. Each PB-TNC batch can contain about 2^24 PA messages. Since PB-TNC supports an unlimited number of batches in a session, this number is actually unlimited (except perhaps by PT protocols, user patience, or other external factors). As for efficiency, PB-TNC adds only 24 octets of overhead per PA message. PA-TNC can include many attributes in a single PA message so this overhead is diluted further.
PB-TNC符合这一要求。每个PB-TNC批次可包含约2^24 PA消息。由于PB-TNC在一个会话中支持无限数量的批处理，这个数量实际上是无限的（除了PT协议、用户耐心或其他外部因素）。就效率而言，PB-TNC仅为每个PA消息增加24个八位字节的开销。PA-TNC可以在单个PA消息中包含许多属性，因此该开销会进一步稀释。
Requirement C-8 says:
要求C-8规定：
C-8 NEA protocols MUST operate efficiently over low bandwidth or high latency links.
C-8 NEA协议必须在低带宽或高延迟链路上高效运行。
PB-TNC meets this requirement. A minimal PB-TNC exchange can be as small as 72 octets and one round trip. Even if privacy policies or other factors require multiple round trips, PB-TNC generally imposes an overhead of only 8 octets per batch and 24 octets per PA message.
PB-TNC符合这一要求。最小PB-TNC交换可以小到72个八位组和一次往返。即使隐私政策或其他因素要求多次往返，PB-TNC通常也只需要每批8个八位字节和每PA消息24个八位字节的开销。
Requirement C-9 says:
要求C-9规定：
C-9 For any strings intended for display to a user, the protocols MUST support adapting these strings to the user's language preferences.
C-9对于打算向用户显示的任何字符串，协议必须支持根据用户的语言偏好调整这些字符串。
PB-TNC meets this requirement. It defines a standard way for the NEA Client and NEA Server to send their language preferences to each other, leveraging the widely implemented Accept-Language format defined in RFC 3282.
PB-TNC符合这一要求。它定义了NEA客户端和NEA服务器相互发送语言首选项的标准方式，利用RFC 3282中定义的广泛实现的Accept语言格式。
Requirement C-10 says:
要求C-10规定：
C-10 NEA protocols MUST support encoding of strings in UTF-8 format.
C-10 NEA协议必须支持UTF-8格式的字符串编码。
PB-TNC meets this requirement. All strings in the PB-TNC protocol are encoded in UTF-8 format. This allows the protocol to support a wide range of languages efficiently.
PB-TNC符合这一要求。PB-TNC协议中的所有字符串都以UTF-8格式编码。这使得协议能够有效地支持多种语言。
Requirement C-11 says:
要求C-11规定：
C-11 Due to the potentially different transport characteristics provided by the underlying candidate PT protocols, the NEA Client and NEA Server MUST be capable of becoming aware of and adapting to the limitations of the available PT protocol. For example, some PT protocol characteristics that might impact the operation of PA and PB include restrictions on which end can initiate a NEA connection, maximum data size in a message or full assessment, upper bound on number of round trips, and ordering (duplex) of messages exchanged. The selection process for the PT protocols MUST consider the limitations the candidate PT protocol would impose upon the PA and PB protocols.
C-11由于潜在候选PT协议提供的潜在不同传输特性，NEA客户端和NEA服务器必须能够意识到并适应可用PT协议的限制。例如，可能影响PA和PB操作的一些PT协议特征包括限制哪一端可以启动NEA连接、消息中的最大数据大小或完全评估、往返次数上限以及交换消息的顺序（双工）。PT协议的选择过程必须考虑候选PT协议对PA和PB协议施加的限制。
PB-TNC meets this requirement. The PB-TNC protocol is designed to be flexible enough to operate with a variety of underlying PT protocols, including those that may have limitations on message or assessment size, number of round trips, and duplex. Local APIs can allow Posture Collectors and Posture Validators to discover when they are operating in a less constrained deployment and then make use of more verbose attributes. Similarly, Posture Collectors could choose not to send or use smaller attributes (including assertions from previous assessments) when faced with a very constrained network connection.
PB-TNC符合这一要求。PB-TNC协议的设计足够灵活，可以与各种基础PT协议一起运行，包括那些可能对消息或评估大小、往返次数和双工有限制的协议。本地API允许姿态采集器和姿态验证器发现它们何时在约束较少的部署中运行，然后使用更详细的属性。类似地，当面临非常受限的网络连接时，姿态收集器可以选择不发送或使用较小的属性（包括以前评估中的断言）。
Requirement PB-1 says:
要求PB-1规定：
PB-1 The PB protocol MUST be capable of carrying attributes from the Posture Broker Server to the Posture Broker Client. This enables the Posture Broker Client to learn the posture assessment decision and if appropriate to aid in remediation and notification of the endpoint owner.
PB-1 PB协议必须能够将属性从姿态代理服务器传输到姿态代理客户端。这使姿态代理客户端能够了解姿态评估决策，并在适当时帮助修复和通知端点所有者。
PB-TNC meets this requirement. It can carry attributes from the Posture Broker Client to the Posture Broker Server and back in an unlimited number of round trips. Furthermore, PB-TNC provides explicit attribute support for posture decision and remediation aid notification.
PB-TNC符合这一要求。它可以将属性从姿态代理客户端传送到姿态代理服务器，并以无限的往返次数返回。此外，PB-TNC为姿势决策和补救辅助通知提供了明确的属性支持。
Requirement PB-2 says:
要求PB-2规定：
PB-2 The PB protocol MUST NOT interpret the contents of PA messages being carried; i.e., the data it is carrying must be opaque to it.
PB-2 PB协议不得解释正在传输的PA消息的内容；i、 例如，它所携带的数据必须是不透明的。
PB-TNC meets this requirement. It does not parse or interpret PA messages in any way.
PB-TNC符合这一要求。它不会以任何方式解析或解释PA消息。
Requirement PB-3 says:
要求PB-3规定：
PB-3 The PB protocol MUST carry unique identifiers that are used by the Posture Brokers to route (deliver) PA messages between Posture Collectors and Posture Validators. Such message routing should facilitate dynamic registration or deregistration of Posture Collectors and Validators. For example, a dynamically registered anti-virus Posture Validator should be able to subscribe to receive messages from its respective anti-virus Posture Collector on NEA Clients.
PB-3 PB协议必须携带姿势代理用于在姿势收集器和姿势验证器之间路由（传递）PA消息的唯一标识符。这种消息路由应该有助于姿态收集器和验证器的动态注册或注销。例如，动态注册的防病毒姿态验证器应该能够订阅以从NEA客户端上的相应防病毒姿态收集器接收消息。
PB-TNC meets this requirement. PB-TNC tags each PA message with a PA subtype that the Posture Brokers can use to deliver the PA messages to the proper Posture Collectors and Posture Validators. By tagging messages according to their content, PB-TNC allows Posture Collectors and Posture Validators to be dynamically registered and deregistered, ensuring that each one receives the proper data. PB-TNC also supports exclusive delivery, which allows messages to be targeted at a particular Posture Collector or Posture Validator.
PB-TNC符合这一要求。PB-TNC使用PA子类型标记每个PA消息，姿势代理可以使用该子类型将PA消息传递给适当的姿势收集器和姿势验证器。PB-TNC根据消息的内容对消息进行标记，从而允许动态注册和注销姿态采集器和姿态验证器，确保每个采集器和姿态验证器都接收到正确的数据。PB-TNC还支持独占传递，这允许消息以特定姿势收集器或姿势验证器为目标。
Requirement PB-4 says:
要求PB-4规定：
PB-4 The PB protocol MUST be capable of supporting a half-duplex PT protocol. However, this does not preclude PB from operating full-duplex when running over a full-duplex PT.
PB-4 PB协议必须能够支持半双工PT协议。然而，这并不妨碍PB在全双工PT上运行时操作全双工。
PB-TNC meets this requirement. In order to insulate PA from any differences between half-duplex and full-duplex PT protocols, PB-TNC always operates in a half-duplex mode, regardless of the capabilities of the PT protocol. While this could in theory slow assessments that require many round trips or bidirectional multimedia exchanges, this is not a problem in practice because endpoint assessments do not typically involve multimedia or a large number of round trips.
PB-TNC符合这一要求。为了将PA与半双工和全双工PT协议之间的任何差异隔离开来，PB-TNC始终以半双工模式运行，而不管PT协议的性能如何。虽然这在理论上可能会减慢需要多次往返或双向多媒体交换的评估，但在实践中这不是一个问题，因为端点评估通常不涉及多媒体或大量往返。
Requirement PB-5 says:
要求PB-5规定：
PB-5 The PB protocol MAY support authentication, integrity, and confidentiality protection for the attribute messages it carries between a Posture Broker Client and Posture Broker Server. This provides security protection for a message dialog of the groupings of attribute messages exchanged between the Posture Broker Client and Posture Broker Server. Such protection is orthogonal to PA protections (which are end to end) and allows for simpler Posture Collector and Validators to be implemented, and for consolidation of cryptographic operations possibly improving scalability and manageability.
PB-5 PB协议可支持对姿态代理客户端和姿态代理服务器之间的属性消息进行身份验证、完整性和机密性保护。这为姿态代理客户端和姿态代理服务器之间交换的属性消息分组的消息对话框提供了安全保护。这种保护与PA保护（端到端）正交，允许实现更简单的姿态收集器和验证器，并允许整合加密操作，可能提高可伸缩性和可管理性。
PB-TNC does not address this optional requirement. It leaves security to PT (which is required to address it) and PA (which SHOULD do so). There seems to be minimal benefit in adding a third layer of security to the NEA protocol stack. However, if the NEA working group determines that PB should include support for authentication, integrity protection, and confidentiality protection, then this could be added to PB in a similar manner to the way that the PA-TNC security is done.
PB-TNC不满足此可选要求。它将安全性留给PT（需要解决它）和PA（应该这样做）。在NEA协议栈中添加第三层安全性似乎没有什么好处。但是，如果NEA工作组确定PB应包括对认证、完整性保护和保密性保护的支持，则可采用与PA-TNC安全类似的方式将其添加到PB中。
Requirement PB-6 says:
要求PB-6规定：
PB-6 The PB protocol MUST support grouping of attribute messages to optimize transport of messages and minimize round trips.
PB-6 PB协议必须支持属性消息分组，以优化消息传输并最小化往返。
PB-TNC meets this requirement. Multiple attribute messages can be conveyed in a single PA message. In fact, that's how PA-TNC works.
PB-TNC符合这一要求。多属性消息可以在单个PA消息中传输。事实上，PA-TNC就是这样运作的。
Authors' Addresses
作者地址
Ravi Sahita Intel Corporation 2200 Mission College Blvd. Santa Clara, CA 95054 USA EMail: Ravi.Sahita@intel.com
拉维萨希塔英特尔公司使命学院大道2200号。加利福尼亚州圣克拉拉95054美国电子邮件：Ravi。Sahita@intel.com
Steve Hanna Juniper Networks, Inc. 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA EMail: shanna@juniper.net
Steve Hanna Juniper Networks，Inc.美国加利福尼亚州桑尼维尔北玛蒂尔达大道1194号，邮编94089电子邮件：shanna@juniper.net
Ryan Hurst Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA EMail: Ryan.Hurst@microsoft.com
瑞安赫斯特微软公司一微软路雷蒙德，华盛顿98052美国电子邮件：瑞安。Hurst@microsoft.com
Kaushik Narayan Cisco Systems Inc. 10 West Tasman Drive San Jose, CA 95134 USA EMail: kaushik@cisco.com
Kaushik Narayan Cisco Systems Inc.美国加利福尼亚州圣何塞西塔斯曼大道10号邮编95134电子邮件：kaushik@cisco.com