Internet Architecture Board (IAB) J. Jimenez
Request for Comments: 8477 H. Tschofenig
Category: Informational D. Thaler
ISSN: 2070-1721 October 2018
Internet Architecture Board (IAB) J. Jimenez
Request for Comments: 8477 H. Tschofenig
Category: Informational D. Thaler
ISSN: 2070-1721 October 2018
Report from the Internet of Things (IoT) Semantic Interoperability (IOTSI) Workshop 2016
2016年物联网（IoT）语义互操作性（IOTSI）研讨会报告
Abstract
摘要
This document provides a summary of the "Workshop on Internet of Things (IoT) Semantic Interoperability (IOTSI)", which took place in Santa Clara, California March 17-18, 2016. The main goal of the workshop was to foster a discussion on the different approaches used by companies and Standards Developing Organizations (SDOs) to accomplish interoperability at the application layer. This report summarizes the discussions and lists recommendations to the standards community. The views and positions in this report are those of the workshop participants and do not necessarily reflect those of the authors or the Internet Architecture Board (IAB), which organized the workshop. Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.
本文件概述了2016年3月17日至18日在加利福尼亚州圣克拉拉举行的“物联网（IoT）语义互操作性（IOTSI）”研讨会。研讨会的主要目标是促进讨论公司和标准开发组织（SDO）在应用层实现互操作性所使用的不同方法。本报告总结了讨论情况，并列出了对标准团体的建议。本报告中的观点和立场是研讨会参与者的观点和立场，不一定反映作者或组织研讨会的互联网架构委员会（IAB）的观点和立场。请注意，本文件是研讨会会议记录的报告。本报告中记录的观点和立场是研讨会参与者的观点和立场，不一定反映IAB的观点和立场。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
本文件是互联网体系结构委员会（IAB）的产品，代表IAB认为有价值提供永久记录的信息。它代表了互联网体系结构委员会（IAB）的共识。IAB批准发布的文件不适用于任何级别的互联网标准；见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8477.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8477.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. What Problems to Solve . . . . . . . . . . . . . . . . . . . 5
4. Translation . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Dealing with Change . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Collaboration . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Informative References . . . . . . . . . . . . . . . . . . . 12
Appendix A. Program Committee . . . . . . . . . . . . . . . . . 14
Appendix B. Accepted Position Papers . . . . . . . . . . . . . . 14
Appendix C. List of Participants . . . . . . . . . . . . . . . . 17
IAB Members at the Time of Approval . . . . . . . . . . . . . . . 18
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. What Problems to Solve . . . . . . . . . . . . . . . . . . . 5
4. Translation . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Dealing with Change . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Collaboration . . . . . . . . . . . . . . . . . . . . . . . . 11
9. Informative References . . . . . . . . . . . . . . . . . . . 12
Appendix A. Program Committee . . . . . . . . . . . . . . . . . 14
Appendix B. Accepted Position Papers . . . . . . . . . . . . . . 14
Appendix C. List of Participants . . . . . . . . . . . . . . . . 17
IAB Members at the Time of Approval . . . . . . . . . . . . . . . 18
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
The Internet Architecture Board (IAB) holds occasional workshops designed to consider long-term issues and strategies for the Internet, and to suggest future directions for the Internet architecture. The investigated topics often require coordinated efforts from many organizations and industry bodies to improve an identified problem. One of the targets of the workshops is to establish communication between relevant organizations, especially when the topics are out of the scope of the Internet Engineering Task Force (IETF). This long-term planning function of the IAB is complementary to the ongoing engineering efforts performed by working groups of the IETF.
互联网体系结构委员会（IAB）举办临时研讨会，旨在考虑互联网的长期问题和策略，并提出未来的互联网架构方向。调查的主题通常需要许多组织和行业机构的协调努力，以改进已识别的问题。研讨会的目标之一是建立相关组织之间的沟通，特别是当主题不在互联网工程任务组（IETF）的范围内时。IAB的长期规划职能是对IETF工作组正在进行的工程工作的补充。
With the expansion of the Internet of Things (IoT), interoperability becomes more and more important. Standards Developing Organizations (SDOs) have done a tremendous amount of work to standardize new protocols and profile existing protocols.
随着物联网的发展，互操作性变得越来越重要。标准开发组织（SDO）已经做了大量的工作来标准化新协议和分析现有协议。
At the application layer and at the level of solution frameworks, interoperability is not yet mature. Particularly, the work on data formats (in the form of data models and information models) has not seen the same level of consistency throughout SDOs.
在应用层和解决方案框架级别，互操作性尚未成熟。特别是，关于数据格式（以数据模型和信息模型的形式）的工作在整个SDO中没有看到相同程度的一致性。
One common problem is the lack of an encoding-independent standardization of the information, the so-called information model. Another problem is the strong relationship between data formats and the underlying communication architecture, such as a design in Remote Procedure Call (RPC) style or a RESTful design (where REST refers to Representational State Transfer). Furthermore, groups develop solutions that are very similar on the surface but differ slightly in their standardized outcome, leading to interoperability problems. Finally, some groups favor different encodings for use with various application-layer protocols.
一个常见的问题是缺乏独立于编码的信息标准化，即所谓的信息模型。另一个问题是数据格式和底层通信体系结构之间的密切关系，例如远程过程调用（RPC）风格的设计或RESTful设计（REST指代表性状态传输）。此外，团队开发的解决方案表面上非常相似，但标准化结果略有不同，从而导致互操作性问题。最后，一些团体倾向于使用不同的编码与各种应用层协议。
Thus, the IAB decided to organize a workshop to reach out to relevant stakeholders to explore the state of the art and identify commonality and gaps [IOTSIAG] [IOTSIWS]. In particular, the IAB was interested to learn about the following aspects:
因此，IAB决定组织一次研讨会，接触相关利益相关者，探索最新技术，并确定共性和差距[IOTSIAG][IOTSIW]。特别是，IAB有兴趣了解以下方面：
o What is the state of the art in data and information models? What should an information model look like?
o 数据和信息模型的最新发展状况如何？信息模型应该是什么样子？
o What is the role of formal languages, such as schema languages, in describing information and data models?
o 形式语言（如模式语言）在描述信息和数据模型时扮演什么角色？
o What is the role of metadata, which is attached to data to make it self-describing?
o 元数据的作用是什么，它附加到数据以使其具有自描述性？
o How can we achieve interoperability when different organizations, companies, and individuals develop extensions?
o 当不同的组织、公司和个人开发扩展时，我们如何实现互操作性？
o What is the experience with interworking various data models developed from different groups, or with data models that evolved over time?
o 不同团队开发的各种数据模型或随时间演变的数据模型的交互工作经验如何？
o What functionality should online repositories for sharing schemas have?
o 共享架构的在线存储库应该具有哪些功能？
o How can existing data models be mapped against each other to offer interworking?
o 现有数据模型如何相互映射以提供互通性？
o Is there room for harmonization, or are the use cases of different groups and organizations so unique that there is no possibility for cooperation?
o 是否有协调的空间，或者不同团体和组织的用例是否如此独特，以至于不可能进行合作？
o How can organizations better work together to increase awareness and information sharing?
o 组织如何更好地协同工作以提高认识和信息共享？
The first roadblock to interoperability at the level of data models is the lack of a common vocabulary to start the discussion. [RFC3444] provides a starting point by separating conceptual models for designers, or "information models", from concrete detailed definitions for implementers, or "data models". There are concepts that are undefined in that RFC and elsewhere, such as the interaction with the resources of an endpoint, or "interaction model". Therefore, the three "main" common models that were identified were:
在数据模型层面上实现互操作性的第一个障碍是缺乏通用词汇表来开始讨论。[RFC3444]通过将设计师的概念模型或“信息模型”与实施者的具体详细定义或“数据模型”分离，提供了一个起点。在RFC和其他地方有一些未定义的概念，例如与端点资源的交互，或“交互模型”。因此，确定的三个“主要”通用模型是：
Information Model An information model defines an environment at the highest level of abstraction and expresses the desired functionality. Information models can be defined informally (e.g., in prose) or more formally (e.g., Unified Modeling Language (UML), Entity-Relationship Diagrams, etc.). Implementation details are hidden.
信息模型信息模型在最高抽象级别定义环境并表达所需的功能。信息模型可以非正式地定义（例如，以散文形式），也可以更正式地定义（例如，统一建模语言（UML）、实体关系图等）。实现细节是隐藏的。
Data Model A data model defines concrete data representations at a lower level of abstraction, including implementation- and protocol-specific details. Some examples are SNMP Management Information Base (MIB) modules, World Wide Web Consortium (W3C) Thing Description (TD) Things, YANG modules, Lightweight Machine-to-Machine (LwM2M) Schemas, Open Connectivity Foundation (OCF) Schemas, and so on.
数据模型数据模型在较低的抽象级别上定义具体的数据表示，包括特定于实现和协议的细节。其中包括SNMP管理信息库（MIB）模块、万维网联盟（W3C）事物描述（TD）、杨氏模块、轻量级机器对机（LWM2M）模式、开放连接基础（OCF）模式等。
Interaction Model An interaction model defines how data is accessed and retrieved from the endpoints, being, therefore, tied to the specific communication pattern that the system has (e.g., REST methods, Publish/Subscribe operations, or RPC calls).
交互模型交互模型定义如何从端点访问和检索数据，因此与系统具有的特定通信模式（例如，REST方法、发布/订阅操作或RPC调用）相关联。
Another identified terminology issue is the semantic meaning overload that some terms have. The meaning can vary depending on the context in which the term is used. Some examples of such terms are as follows: semantics, models, encoding, serialization format, media types, and encoding types. Due to time constraints, no concrete terminology was agreed upon, but work will continue within each organization to create various terminology documents. The participants agreed to set up a GitHub repository [IOTSIGIT] for sharing information.
另一个已确定的术语问题是某些术语的语义过载。含义可能因使用该术语的上下文而异。这些术语的一些示例如下：语义、模型、编码、序列化格式、媒体类型和编码类型。由于时间限制，没有商定具体的术语，但将在每个组织内继续编写各种术语文件。与会者同意建立一个GitHub存储库[IOTSIGIT]，用于共享信息。
The participants agreed that there is not simply a single problem to be solved but rather a range of problems. During the workshop, the following problems were discussed:
与会者一致认为，需要解决的不仅仅是一个问题，而是一系列问题。在研讨会期间，讨论了以下问题：
o Formal Languages for Documentation Purposes
o 用于文档编制的正式语言
To simplify review and publication, SDOs need formal descriptions of their data and interaction models. Several of them use a tabular representation found in the specification itself but use a formal language as an alternative way of describing objects and resources for formal purposes. Some examples of formal language use are as follows.
为了简化审查和发布，SDO需要对其数据和交互模型进行正式描述。其中一些使用规范本身中的表格表示法，但使用形式化语言作为描述对象和资源的替代方法，以达到形式化目的。下面是一些正式语言使用的例子。
The Open Mobile Alliance (OMA), now OMA SpecWorks, used an XML Schema [LWM2M-Schema] to describe their object and resource definitions. The XML files of standardized objects are available for download at [OMNA].
开放移动联盟（OMA），现在的OMA SpecWorks，使用XML模式[LWM2M模式]来描述他们的对象和资源定义。标准化对象的XML文件可从[OMNA]下载。
The Bluetooth Special Interest Group (SIG) defined Generic Attribute Profile (GATT) services and characteristics for use with Bluetooth Smart/Low Energy. The services and characteristics are shown in a tabular form on the Bluetooth SIG website [SIG] and are defined as XML instance documents.
Bluetooth Special Interest Group（SIG）定义了通用属性配置文件（GATT）服务和特性，用于Bluetooth Smart/Low Energy。服务和特性以表格形式显示在Bluetooth SIG网站[SIG]上，并定义为XML实例文档。
The Open Connectivity Foundation (OCF) uses JSON Schemas to formally define data models and RESTful API Modeling Language (RAML) to define interaction models. The standard files are available online at <oneIoTa.org>.
开放连接基础（OCF）使用JSON模式来正式定义数据模型和REST API建模语言（RAML）来定义交互模型。标准文件可在线访问<oneIoTa.org>。
The AllSeen Alliance uses AllJoyn Introspection XML to define data and interaction models in the same formal language, tailored for RPC-style interaction. The standard files are available online on the AllSeen Alliance website, but both standard and vendor-defined model files can be obtained by directly querying a device for them at runtime.
AllSeen联盟使用AllJoyn内省XML以相同的形式语言定义数据和交互模型，为RPC风格的交互定制。标准文件可在AllSeen联盟网站上在线获取，但标准和供应商定义的模型文件都可以通过在运行时直接查询设备来获取。
The World Wide Web Consortium (W3C) uses the Resource Description Framework (RDF) to define data and interaction models using a format tailored for the web.
万维网联盟（W3C）使用资源描述框架（RDF）定义数据和交互模型，使用为Web定制的格式。
The Internet Engineering Task Force (IETF) uses YANG to define data and interaction models. Other SDOs may use various other formats.
互联网工程任务组（IETF）使用YANG定义数据和交互模型。其他SDO可以使用各种其他格式。
o Formal Languages for Code Generation
o 用于代码生成的形式语言
Code-generation tools that use formal data and information modeling languages are needed by developers. For example, the AllSeen Visual Studio Plugin [AllSeen-Plugin] offers a wizard to generate code based on the formal description of the data model. Another example of a data modeling language that can be used for code generation is YANG. A popular tool to help with code generation of YANG modules is pyang [PYANG]. An example of a tool that can generate code for multiple ecosystems is OpenDOF [OpenDOF]. Use cases discussed for code generation included easing development of server-side device functionality, clients, and compliance tests.
开发人员需要使用正式数据和信息建模语言的代码生成工具。例如，AllSeen Visual Studio插件[AllSeen Plugin]提供了一个基于数据模型的形式化描述生成代码的向导。YANG是可用于代码生成的数据建模语言的另一个示例。pyang[pyang]是帮助生成YANG模块代码的流行工具。可以为多个生态系统生成代码的工具的一个例子是OpenDOF[OpenDOF]。讨论的代码生成用例包括简化服务器端设备功能的开发、客户端和遵从性测试。
o Debugging Support
o 调试支持
Debugging tools are needed that implement generic object browsers, which use standard data models and/or retrieve formal language descriptions from the devices themselves. As one example, the nRF Bluetooth Smart sniffer from Nordic Semiconductor [nRF-Sniffer] can be used to display services and characteristics defined by the Bluetooth SIG. As another example, AllJoyn Explorer [AllJoynExplorer] can be used to browse and interact with any resource exposed by an AllJoyn device, including both standard and vendor-defined data models, by retrieving the formal descriptions from the device at runtime.
需要调试工具来实现通用对象浏览器，这些浏览器使用标准数据模型和/或从设备本身检索正式的语言描述。例如，Nordic Semiconductor[nRF sniffer]的nRF Bluetooth Smart sniffer可用于显示由Bluetooth SIG定义的服务和特征。作为另一个示例，AllJoyn Explorer[AllJoynExplorer]可用于浏览AllJoyn设备公开的任何资源并与之交互，包括标准和供应商定义的数据模型，方法是在运行时从设备检索正式描述。
o Translation
o 翻译
The working assumption is that devices need to have a common data model with a priori knowledge of data types and actions. However, that would imply that each consortium/organization will try to define their own data model. That would cause a major interoperability
工作假设是，设备需要有一个公共数据模型，该模型具有数据类型和操作的先验知识。然而，这意味着每个财团/组织将试图定义自己的数据模型。这将导致一个重大的互操作性问题
problem, possibly a completely intractable one given the number of variations, extensions, compositions, or versioning changes that will happen for each data model.
考虑到每个数据模型将发生的变化、扩展、组合或版本控制更改的数量，这可能是一个完全难以解决的问题。
Another potential approach is to have a minimal amount of information on the device to allow for a runtime binding to a specific model, the objective being to require as little prior knowledge as possible.
另一种可能的方法是在设备上拥有最少的信息，以允许运行时绑定到特定模型，目标是尽可能少地需要先验知识。
Moreover, gateways, bridges and other similar devices need to dynamically translate (or map) one data model to another one. Complexity will increase as there are also multiple protocols and schemas that make interoperability harder to achieve.
此外，网关、网桥和其他类似设备需要动态地将一个数据模型转换（或映射）到另一个数据模型。复杂性将增加，因为还有多个协议和模式使得互操作性更难实现。
o Runtime Discovery
o 运行时发现
Runtime discovery allows IoT devices to exchange metadata about the data, potentially along with the data exchanged itself. In some cases, the metadata not only describes data but also the interaction model as well. An example of such an approach has been shown with Hypermedia as the Engine of Application State (HATEOAS) [HATEOAS]. Another example is that all AllJoyn devices support such runtime discovery using a protocol mechanism called "introspection", where the metadata is queried from the device itself [AllSeen].
运行时发现允许物联网设备交换有关数据的元数据，可能还包括交换的数据本身。在某些情况下，元数据不仅描述数据，还描述交互模型。超媒体作为应用程序状态引擎（HATEOAS）[HATEOAS]就是这种方法的一个例子。另一个例子是，所有AllJoyn设备都支持使用称为“内省”的协议机制进行这种运行时发现，其中元数据是从设备本身查询的[AllSeen]。
There are various models, whether deployed or possible, for such discovery. The metadata might be extracted from a specification, looked up on a cloud repository (e.g., oneIoTa for OCF models), looked up via a vendor's site, or obtained from the device itself (such as in the AllJoyn case). The relevant metadata might be obtained from the same place or different pieces might be obtained from different places, such as separately obtaining (a) syntax information, (b) end-user descriptions in a desired language, and (c) developer-specific comments for implementers.
对于这种发现，有各种各样的模型，无论是部署的还是可能的。元数据可以从规范中提取、在云存储库中查找（例如，OCF模型的oneIoTa）、通过供应商的站点查找或从设备本身获取（例如AllJoyn案例）。相关元数据可以从同一个地方获得，也可以从不同的地方获得，例如分别获得（a）语法信息，（b）所需语言的最终用户描述，以及（c）针对实现者的特定于开发人员的注释。
In an ideal world where organizations and companies cooperate and agree on a single data model standard, there is no need for gateways that translate from one data model to another one. However, this is far from reality today, and there are many proprietary data models in addition to the already standardized ones. As a consequence, gateways are needed to translate between data models. This leads to (n^2)-n combinations, in the worst case.
在一个理想的世界中，组织和公司在一个单一的数据模型标准上进行合作并达成一致，因此不需要从一个数据模型转换到另一个数据模型的网关。然而，这与今天的现实相去甚远，除了已经标准化的数据模型之外，还有许多专有数据模型。因此，需要网关在数据模型之间进行转换。在最坏的情况下，这会导致（n^2）-n个组合。
There are analogies with gateways back in the 1980s that were used to translate between network layer protocols. Eventually, IP took over, providing the necessary end-to-end interoperability at the network layer. Unfortunately, the introduction of gateways leads to the loss
早在20世纪80年代，网关就被用来在网络层协议之间进行转换。最终，IP接管了网络，在网络层提供了必要的端到端互操作性。不幸的是，网关的引入导致了损失
of expressiveness due to the translation between data models. The functionality of IP was so valuable in the market that advanced features of other networking protocols became less attractive and were not used anymore.
由于数据模型之间的转换而导致的表达能力下降。IP的功能在市场上非常有价值，以至于其他网络协议的高级功能变得不那么吸引人，不再使用。
Participants discussed an alternative that they called a "red star", shown in Figure 1, where data models are translated to a common data model shown in the middle. This reduces the number of translations that are needed down to 2n (in the best case). The problem, of course, is that everyone wants their own data model to be the red star in the center.
与会者讨论了一种替代方案，他们称之为“红星”，如图1所示，其中数据模型被转换为中间显示的公共数据模型。这将需要的翻译数量减少到2n（在最佳情况下）。当然，问题是每个人都希望自己的数据模型成为中心的红星。
+-----+ +-----+
| | | |
| | -- -- | |
| | -- -- | |
+-----+ -- -- +-----+
-- ---
-- --
-- --
-- --
--- -- A -- ---
/ \ ___/ \___ / \
| | ---------------', .'--------------- | |
\ / /. ^ .\ \ /
--- /' '\ ---
-- --
-- --
-- --
-- --
-- --
/\ -- -- /\
/ \ -- -- / \
/ \ / \
/ \ / \
/--------\ /--------\
+-----+ +-----+
| | | |
| | -- -- | |
| | -- -- | |
+-----+ -- -- +-----+
-- ---
-- --
-- --
-- --
--- -- A -- ---
/ \ ___/ \___ / \
| | ---------------', .'--------------- | |
\ / /. ^ .\ \ /
--- /' '\ ---
-- --
-- --
-- --
-- --
-- --
/\ -- -- /\
/ \ -- -- / \
/ \ / \
/ \ / \
/--------\ /--------\
Figure 1: The "Red Star" in Data/Information Models
图1：数据/信息模型中的“红星”
While the workshop itself was not a suitable forum to discuss the design of such translation in detail, several questions were raised:
虽然讲习班本身不是详细讨论此类翻译设计的合适论坛，但提出了几个问题：
o Do we need a "red star" that does everything, or could we design something that offers a more restricted functionality?
o 我们是否需要一个无所不能的“红星”，或者我们是否可以设计一些提供更严格功能的东西？
o How do we handle loss of data and functionality?
o 我们如何处理数据和功能的丢失？
o Should data be translated between data models, or should data models themselves be translated?
o 数据应该在数据模型之间转换，还是数据模型本身应该转换？
o How can interaction models be translated? They need to be dealt with in addition to the data models.
o 如何翻译交互模型？除了数据模型之外，还需要处理它们。
o Many (if not all) data and interaction models have some bizarre functionality that cannot be translated easily. How can those be handled?
o 许多（如果不是全部的话）数据和交互模型都有一些难以翻译的奇怪功能。如何处理这些问题？
o What limitations are we going to accept in these translations?
o 在这些翻译中，我们将接受哪些限制？
The participants also addressed the question of when translation should be done. Two use cases were discussed:
与会者还讨论了何时进行翻译的问题。讨论了两个用例：
(a) Design time: A translation between data model descriptions, such as translating a YANG module to a RAML/JSON model, can be performed once, during design time. A single information model might be mapped to a number of different data models.
(a) 设计时：数据模型描述之间的转换，例如将YANG模块转换为RAML/JSON模型，可以在设计时执行一次。单个信息模型可能映射到多个不同的数据模型。
(b) Run time: Runtime translation of values in two standard data models can only be algorithmically done when the data model on one side is algorithmically derived from the data model on the other side. This was called a "derived model". It was discussed that the availability of runtime discovery can aid in semantic translation, such as when a vendor-specific data model on one side of a protocol bridge is resolved and the translator can algorithmically derive the semantically equivalent vendor-specific data model on the other side. This situation is discussed in [BridgeTaxonomy].
(b) 运行时：两个标准数据模型中的值的运行时转换只能在一边的数据模型通过算法从另一边的数据模型派生时通过算法完成。这被称为“衍生模型”。据讨论，运行时发现的可用性有助于语义转换，例如，当协议网桥一侧的供应商特定数据模型被解析时，翻译器可以通过算法推导另一侧的语义等效供应商特定数据模型。这种情况在[BridgeTaxonomy]中讨论。
The participants agreed that algorithm translation will generally require custom code whenever one is translating to anything other than a derived model.
与会者一致认为，算法翻译通常需要自定义代码，只要转换为衍生模型以外的任何对象。
Participants concluded that it is typically easier to translate data between systems that follow the same communication architecture.
参与者得出结论，在遵循相同通信架构的系统之间转换数据通常更容易。
A large part of the workshop was dedicated to the evolution of devices and server-side applications. Interactions between devices and services and how their relationship evolves over time is complicated by their respective interaction models.
研讨会的大部分内容都致力于设备和服务器端应用程序的发展。设备和服务之间的交互以及它们之间的关系如何随着时间的推移而演变是由它们各自的交互模型造成的。
The workshop participants discussed various approaches to deal with change. In the most basic case, a developer might use a description of an API and implement the protocol steps. Sometimes, the data or
讲习班与会者讨论了应对变化的各种方法。在最基本的情况下，开发人员可能会使用API的描述并实现协议步骤。有时，数据或
information model can be used to generate code stubs. Subsequent changes to an API require changes on the clients to upgrade to the new version, which requires some development of new code to satisfy the needs of the new API.
信息模型可用于生成代码存根。对API的后续更改需要对客户端进行更改以升级到新版本，这需要开发一些新代码以满足新API的需要。
These interactions could be made machine understandable in the first place, enabling for changes to happen at runtime. In that scenario, a machine client could discover the possible interactions with a service, adapting to changes as they occur without specific code being developed to adapt to them.
这些交互首先可以让机器理解，从而使更改能够在运行时发生。在这种情况下，机器客户机可以发现与服务的可能交互，在发生更改时进行调整，而无需开发特定代码来适应这些更改。
The challenge seems to be to code the human-readable specification into a machine-readable format. Machine-readable languages require a shared vocabulary to give meaning to the tags.
挑战似乎是将人类可读的规范编码为机器可读的格式。机器可读语言需要一个共享词汇表来赋予标记意义。
These types of interactions are often based on the REST architectural style. Its principle is that a device or endpoint only needs a single entry point, with a host providing descriptions of the API in-band by means of web links and forms.
这些类型的交互通常基于REST体系结构样式。其原理是设备或端点只需要一个入口点，主机通过web链接和表单提供带内API的描述。
By defining IoT-specific relation types, it is possible to drive interactions through links instead of hard-coding URIs into a RESTful client, thus making the system flexible enough for later changes. The definition of the basic hypermedia formats for IoT is still a work in progress. However, some of the existing mechanisms can be reused, such as resource discovery, forms, or links.
通过定义物联网特定的关系类型，可以通过链接驱动交互，而不是将URI硬编码到RESTful客户机中，从而使系统具有足够的灵活性，可以进行后续更改。物联网基本超媒体格式的定义仍在进行中。但是，一些现有机制可以重用，例如资源发现、表单或链接。
This document has no IANA actions.
本文档没有IANA操作。
There were two types of security considerations discussed: use of formal data models for security configuration and security of data and data models in general.
讨论了两种类型的安全注意事项：使用正式数据模型进行安全配置，以及数据和数据模型的安全性。
It was observed that the security assumptions and configuration, or "security model", varies by ecosystem today, making the job of a translator difficult. For example, there are different types of security principals (e.g., user vs. device vs. application), the use of Access Control Lists (ACLs) versus capabilities, and what types of policies can be expressed, all vary by ecosystem. As a result, the security model architecture generally dictates where translation can be done.
据观察，安全假设和配置，或“安全模型”，因今天的生态系统而异，使翻译工作变得困难。例如，存在不同类型的安全主体（例如，用户与设备与应用程序），访问控制列表（ACL）与功能的使用，以及可以表达的策略类型，所有这些都因生态系统而异。因此，安全模型体系结构通常规定可以在何处进行翻译。
One approach discussed was whether two endpoints might be able to use some overlay security model across a translator between two ecosystems, which only works if the two endpoints agree on a common data model for their communication. Another approach discussed was simply having a translator act as a trusted intermediary, which enables the translator to translate between different data models.
讨论的一种方法是，两个端点是否能够跨两个生态系统之间的转换器使用某种覆盖安全模型，这只有在两个端点就其通信的公共数据模型达成一致时才有效。讨论的另一种方法是让翻译人员充当可信的中介，这使翻译人员能够在不同的数据模型之间进行翻译。
One suggestion discussed was either adding metadata into the formal data model language or having it accompany the data values over the wire, tagging the data with privacy levels. However, sometimes even the privacy level of information might itself be sensitive. Still, it was observed that being able to dynamically learn security requirements might help provide better UIs and translators.
讨论的一个建议是，要么将元数据添加到正式的数据模型语言中，要么让它通过网络伴随数据值，用隐私级别标记数据。然而，有时甚至信息的隐私级别本身也可能是敏感的。不过，有人认为，能够动态了解安全需求可能有助于提供更好的UI和翻译人员。
The participants discussed how best to share information among their various organizations. One discussion was around having joint meetings. One current challenge reported was that organizations were not aware of when and where each other's meetings were scheduled, and sharing such information could help organizations better collocate meetings. To facilitate this exchange, the participants agreed to add links to their respective meeting schedules from a common page in the IOTSI repository [IOTSIGIT].
与会者讨论了如何最好地在各组织之间共享信息。一次讨论是关于举行联席会议。据报道，目前的一个挑战是，各组织不知道彼此的会议安排在何时何地，而共享此类信息有助于各组织更好地安排会议。为了促进交流，与会者同意从IOTSI存储库[IOTSIGIT]中的公共页面添加到各自会议日程的链接。
Another challenge reported was that organizations did not know how to find each other's published data models, and sharing such information could better facilitate reuse of the same information model. To facilitate this exchange, the participants discussed whether a common repository might be used by multiple organizations. The OCF's oneIoTa repository was discussed as one possibility, but it was reported that its terms of use at the time of the workshop prevented this. The OCF agreed to take this back and look at updating the terms of use to allow other organizations to use it, as the restriction was not the intent. <schema.org> was discussed as another possibility. In the meantime, the participants agreed to add links to their respective repositories from a common page in the IOTSI repository [IOTSIGIT].
报告的另一个挑战是，组织不知道如何找到彼此发布的数据模型，共享此类信息可以更好地促进相同信息模型的重用。为了促进这种交流，与会者讨论了公共存储库是否可供多个组织使用。OCF的oneIoTa存储库作为一种可能性进行了讨论，但据报道，研讨会时的使用条款阻止了这一点。OCF同意收回这一点，并考虑更新使用条款，以允许其他组织使用它，因为限制并非目的<schema.org>作为另一种可能性进行了讨论。同时，参与者同意从IOTSI存储库[IOTSIGIT]的公共页面添加到各自存储库的链接。
It was also agreed that the iotsi@iab.org mailing list would remain open and available for sharing information between all relevant organizations.
会议还商定iotsi@iab.org邮寄名单将继续开放，供所有相关组织共享信息。
[AllJoynExplorer] Microsoft, "AllJoyn".
[AllJoynExplorer]微软，“AllJoyn”。
[AllSeen] Thaler, D., "Summary of AllSeen Alliance Work Relevant to Semantic Interoperability", 2016, <https://www.iab.org/ wp-content/IAB-uploads/2016/03/AllSeen-summary-IOTSI.pdf>.
[AllSeen]Thaler，D.“与语义互操作性相关的AllSeen联盟工作总结”，2016年<https://www.iab.org/ wp content/IAB uploads/2016/03/AllSeen summary IOTSI.pdf>。
[AllSeen-Plugin] Rockwell, B., "Using the AllJoyn Studio Extension", August 2015.
[AllSeen插件]Rockwell，B.，“使用AllJoyn Studio扩展”，2015年8月。
[BridgeTaxonomy] Thaler, D., "IoT Bridge Taxonomy", IAB IOTSI Workshop 2016, <https://www.iab.org/wp-content/ IAB-uploads/2016/03/DThaler-IOTSI.pdf>.
[BridgeTaxonomy]Thaler，D.，“物联网桥梁分类学”，IAB物联网国际研讨会2016<https://www.iab.org/wp-content/ IAB上传/2016/03/DThaler IOTSI.pdf>。
[HATEOAS] Kovatsch, M., Hassan, Y., and K. Hartke, "Semantic Interoperability Requires Self-describing Interaction Models: HATEOAS for the Internet of Things", Proceedings of the IAB IoT Semantic Interoperability Workshop 2016, <https://www.iab.org/wp-content/ IAB-uploads/2016/03/2016-IAB-HATEOAS.pdf>.
[HATEOAS]Kovatsch，M.，Hassan，Y.，和K.Hartke，“语义互操作性需要自描述交互模型：物联网的HATEOAS”，2016年IAB物联网语义互操作性研讨会论文集<https://www.iab.org/wp-content/ IAB上传/2016/03/2016-IAB-HATEOAS.pdf>。
[IOTSIAG] IAB, "IoT Semantic Interoperability Workshop Agenda", 2016, <https://www.iab.org/activities/workshops/iotsi/agenda/>.
[IOTSIAG]IAB，“IoT语义互操作性研讨会议程”，2016年<https://www.iab.org/activities/workshops/iotsi/agenda/>.
[IOTSIGIT] "Starting place for the IoT Semantic Interoperability Workshop (IOTSI) Information Resource", commit ff21f74, July 2018, <https://github.com/iotsi/iotsi>.
[IOTSIGIT]“IoT语义互操作性研讨会（IOTSI）信息资源的起点”，提交ff21f74，2018年7月<https://github.com/iotsi/iotsi>.
[IOTSIWS] IAB, "IoT Semantic Interoperability Workshop 2016", 2016, <https://www.iab.org/activities/workshops/iotsi/>.
[IOTSIWS]IAB，“2016年IoT语义互操作性研讨会”，2016年<https://www.iab.org/activities/workshops/iotsi/>.
[LWM2M-Schema] OMA, "LWM2M XML Schema - LWM2M Editor Schema", July 2018.
[LWM2M模式]OMA，“LWM2MXML模式-LWM2M编辑器模式”，2018年7月。
[nRF-Sniffer] Nordic Semiconductor, "nRF Sniffer: Smart/Bluetooth low energy packet sniffer".
[nRF嗅探器]北欧半导体，“nRF嗅探器：智能/蓝牙低能量数据包嗅探器”。
[OMNA] OMA, "OMA LightweightM2M (LwM2M) Object and Resource Registry".
[OMNA]OMA，“OMA LightweightM2M（LwM2M）对象和资源注册表”。
[OpenDOF] OpenDOF, "The OpenDOF Project", <https://opendof.org>.
[OpenDOF]OpenDOF，“OpenDOF项目”<https://opendof.org>.
[PYANG] "An extensible YANG validator and converter in python", commit 15c807f, September 2018, <https://github.com/mbj4668/pyang>.
[PYANG]“python中的可扩展YANG验证程序和转换器”，提交15c807f，2018年9月<https://github.com/mbj4668/pyang>.
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, DOI 10.17487/RFC3444, January 2003, <https://www.rfc-editor.org/info/rfc3444>.
[RFC3444]Pras，A.和J.Schoenwaeld，“关于信息模型和数据模型之间的差异”，RFC 3444，DOI 10.17487/RFC3444，2003年1月<https://www.rfc-editor.org/info/rfc3444>.
[SIG] Bluetooth SIG, "GATT Specifications", <https://www.bluetooth.com/specifications/gatt>.
[SIG]蓝牙SIG，“GATT规范”<https://www.bluetooth.com/specifications/gatt>.
This workshop was organized by the following individuals: Jari Arkko, Ralph Droms, Jaime Jimenez, Michael Koster, Dave Thaler, and Hannes Tschofenig.
本次研讨会由以下个人组织：贾里·阿尔科、拉尔夫·德罗姆斯、杰米·希门尼斯、迈克尔·科斯特、戴夫·泰勒和汉内斯·茨霍芬尼。
o Jari Arkko, "Gadgets and Protocols Come and Go, Data Is Forever"
o Jari Arkko，“小工具和协议来来往往，数据是永恒的”
o Carsten Bormann, "Noise in Specifications hurts"
o Carsten Bormann，“规范中的噪音伤害”
o Benoit Claise, "YANG as the Data Modelling Language in the IoT space"
o Benoit Claise，“YANG作为物联网空间中的数据建模语言”
o Robert Cragie, "The ZigBee Cluster Library over IP"
o Robert Cragie，“IP上的ZigBee群集库”
o Dee Denteneer, Michael Verschoor, and Teresa Zotti, "Fairhair: interoperable IoT services for major Building Automation and Lighting Control ecosystems"
o Dee Dentener、Michael Verschoor和Teresa Zotti，“Fairhair：主要楼宇自动化和照明控制生态系统的互操作物联网服务”
o Universal Devices, "Object Oriented Approach to IoT Interoperability"
o 通用设备，“物联网互操作性的面向对象方法”
o Bryant Eastham, "Interoperability and the OpenDOF Project"
o Bryant Eastham，“互操作性和OpenDOF项目”
o Stephen Farrell and Alissa Cooper, "It's Often True: Security's Ignored (IOTSI) - and Privacy too"
o 斯蒂芬·法雷尔（Stephen Farrell）和艾莉莎·库珀（Alissa Cooper），“这通常是真的：安全被忽视（IOTSI）——隐私也被忽视。”
o Christian Groves, Lui Yan, and Yang Weiwei, "Overview of IoT semantics landscape"
o Christian Groves、Lui Yan和Yang Weiwei，“物联网语义景观概述”
o Ted Hardie, "Loci of Interoperability for the Internet of Things"
o Ted Hardie，“物联网互操作性的位置”
o Russ Housley, "Vehicle-to-Vehicle and Vehicle-to-Infrastructure Communications"
o Russ Housley，“车对车和车对基础设施通信”
o Jaime Jimenez, Michael Koster, and Hannes Tschofenig, "IPSO Smart Objects"
o Jaime Jimenez、Michael Koster和Hannes Tschofenig，“IPSO智能对象”
o David Jones, "IOTDB - interoperability Through Semantic Metastandards"
o David Jones，“IOTDB-通过语义元标准的互操作性”
o Sebastian Kaebisch and Darko Anicic, "Thing Description as Enabler of Semantic Interoperability on the Web of Things"
o Sebastian Kaebisch和Darko Anicic，“物描述作为物联网语义互操作性的促成因素”
o Achilleas Kemos, "Alliance for Internet of Things Innovation Semantic Interoperability Release 2.0, AIOTI WG03 - IoT Standardisation"
o Achilleas Kemos，“物联网创新联盟语义互操作性2.0版，AIOTI WG03-物联网标准化”
o Ari Keraenen and Cullen Jennings, "SenML: simple building block for IoT semantic interoperability"
o Ari Keraenen和Cullen Jennings，“SenML：物联网语义互操作性的简单构建块”
o Dongmyoung Kim, Yunchul Choi, and Yonggeun Hong, "Research on Unified Data Model and Framework to Support Interoperability between IoT Applications"
o Kim Dongmyong，Yunchul Choi和Yonggeun Hong，“支持物联网应用程序之间互操作性的统一数据模型和框架研究”
o Michael Koster, "Model-Based Hypertext Language"
o Michael Koster，“基于模型的超文本语言”
o Matthias Kovatsch, Yassin N. Hassan, and Klaus Hartke, "Semantic Interoperability Requires Self-describing Interaction Models"
o Matthias Kovatsch、Yassin N.Hassan和Klaus Hartke，“语义互操作性需要自描述交互模型”
o Kai Kreuzer, "A Pragmatic Approach to Interoperability in the Internet of Things"
o Kai Kreuzer，“物联网互操作性的实用方法”
o Barry Leiba, "Position Paper"
o 巴里·莱巴，“立场文件”
o Marcello Lioy, "AllJoyn"
o Marcello Lioy，“AllJoyn”
o Kerry Lynn and Laird Dornin, "Modeling RESTful APIs with JSON Hyper-Schema"
o Kerry Lynn和Laird Dornin，“使用JSON超模式建模RESTful API”
o Erik Nordmark, "Thoughts on IoT Semantic Interoperability: Scope of security issues"
o Erik Nordmark，“物联网语义互操作性的思考：安全问题的范围”
o Open Geospatial Consortium, "OGC SensorThings API: Communicating "Where" in the Web of Things"
o 开放地理空间联盟，“OGC SensorThings API：在物联网中的“何处”通信”
o Jean Paoli and Taqi Jaffri, "IoT Information Model Interoperability: An Open, Crowd-Sourced Approach in Three Parallel Parti"
o Jean Paoli和Taqi Jaffri，“物联网信息模型互操作性：三个平行部分中的开放、众包方法”
o Joaquin Prado, "OMA Lightweight M2M Resource Model"
o Joaquin Prado，“OMA轻量级M2M资源模型”
o Dave Raggett and Soumya Kanti Datta, "Input paper for IAB Semantic Interoperability Workshop"
o Dave Raggett和Soumya Kanti Datta，“IAB语义互操作性研讨会的输入文件”
o Pete Rai and Stephen Tallamy, "Semantic Overlays Over Immutable Data to Facilitate Time and Context Specific Interoperability"
o Pete Rai和Stephen Tallamy，“不可变数据上的语义覆盖，以促进特定于时间和上下文的互操作性”
o Jasper Roes and Laura Daniele, "Towards semantic interoperability in the IoT using the Smart Appliances REFerence ontology (SAREF) and its extensions"
o Jasper Roes和Laura Daniele，“使用智能设备参考本体（SAREF）及其扩展实现物联网中的语义互操作性”
o Max Senges, "Submission for IAB IoT Sematic Interoperability workshop"
o Max Senges，“IAB物联网语义互操作性研讨会提交”
o Bill Silverajan, Mert Ocak and Jaime Jimenez, "Implementation Experiences of Semantic Interoperability for RESTful Gateway Management"
o Bill Silverajan、Mert Ocak和Jaime Jimenez，“RESTful网关管理语义互操作性的实现经验”
o Ned Smith, Jeff Sedayao, and Claire Vishik, "Key Semantic Interoperability Gaps in the Internet-of-Things Meta-Models"
o Ned Smith、Jeff Sedayao和Claire Vishik，“物联网元模型中的关键语义互操作性缺口”
o Robert Sparks and Ben Campbell, "Considerations for certain IoT-based services"
o Robert Sparks和Ben Campbell，“某些基于物联网的服务的考虑因素”
o J. Clarke Stevens, "Open Connectivity Foundation oneIoTa Tool"
o J. Clarke Stevens，“开放连接基金会ONEOTA工具”
o J. Clarke Stevens and Piper Merriam, "Derived Models for Interoperability Between IoT Ecosystems"
o J.Clarke Stevens和Piper Merriam，“物联网生态系统之间互操作性的衍生模型”
o Ravi Subramaniam, "Semantic Interoperability in Open Connectivity Foundation (OCF) - formerly Open Interconnect Consortium (OIC)"
o Ravi Subramaniam，“开放互联基础（OCF）中的语义互操作性——以前开放互连联盟（OIC）”
o Andrew Sullivan, "Position paper for IOTSI workshop"
o Andrew Sullivan，“IOTSI研讨会的立场文件”
o Darshak Thakore, "IoT Security in the context of Semantic Interoperability"
o Darshak Thakore，“语义互操作性背景下的物联网安全”
o Dave Thaler, "IoT Bridge Taxonomy"
o Dave Thaler，“物联网桥梁分类法”
o Dave Thaler, "Summary of AllSeen Alliance Work Relevant to Semantic Interoperability"
o Dave Thaler，“与语义互操作性相关的AllSeen联盟工作总结”
o Mark Underwood, Michael Gruninger, Leo Obrst, Ken Baclawski, Mike Bennett, Gary Berg-Cross, Torsten Hahmann, and Ram Sriram, "Internet of Things: Toward Smart Networked Systems and Societies"
o 马克·安德伍德、迈克尔·格鲁宁格、利奥·奥斯特、肯·巴克拉夫斯基、迈克·贝内特、加里·伯格·克罗斯、托尔斯滕·哈曼和拉姆·斯里拉姆，“物联网：走向智能网络系统和社会”
o Peter van der Stok and Andy Bierman, "YANG-Based Constrained Management Interface (CoMI)"
o Peter van der Stok和Andy Bierman，“基于YANG的受限管理界面（CoMI）”
Andy Bierman, YumaWorks Carsten Bormann, Uni Bremen/TZI Ben Campbell, Oracle Benoit Claise, Cisco Alissa Cooper, Cisco Robert Cragie, ARM Limited Laura Daniele, TNO Bryant Eastham, OpenDOF Christian Groves, Huawei Ted Hardie, Google Yonggeun Hong, ETRI Russ Housley, Vigil Security David Janes, IOTDB Jaime Jimenez, Ericsson Shailendra Karody, Catalina Labs Ari Keraenen, Ericsson Michael Koster, SmartThings Matthias Kovatsch, Siemens Kai Kreuzer, Deutsche Telekom Barry Leiba, Huawei Steve Liang, Uni Calgary Marcello Lioy, Qualcomm Kerry Lynn, Verizon Mayan Mathen, Catalina Labs Erik Nordmark, Arista Jean Paoli, Microsoft Joaquin Prado, OMA Dave Raggett, W3C Max Senges, Google Ned Smith, Intel Robert Sparks, Oracle Ram Sriram, NIST Clarke Stevens Ram Subramanian, Intel Andrew Sullivan, DIN Darshak Thakore, CableLabs Dave Thaler, Microsoft Hannes Tschofenig, ARM Limited Michael Verschoor, Philips Lighting
Andy Bierman、YumaWorks Carsten Bormann、Uni-Breme/TZI Ben Campbell、Oracle Benoit Claise、Cisco Alissa Cooper、Cisco Robert Cragie、ARM Limited Laura Daniele、TNO Bryant Eastham、OpenDOF Christian Groves、华为Ted Hardie、谷歌永坤Honggeun Hong、ETRI Russ Housley、守夜保安David Janes、IOTDB Jaime Jimenez、爱立信Shailendra Karody、，卡特琳娜实验室Ari Keraenen、爱立信Michael Koster、SmartThings Matthias Kovatsch、西门子Kai Kreuzer、德国电信巴里·莱巴、华为Steve Liang、卡尔加里大学Marcello Lioy、高通公司Kerry Lynn、Verizon Mayan Mathen、卡特琳娜实验室Erik Nordmark、Arista Jean Paoli、微软公司Joaquin Prado、OMA Dave Raggett、W3C Max Senges、谷歌公司Ned Smith、，Intel Robert Sparks、Oracle Ram Sriram、NIST Clarke Stevens Ram Subramanian、Intel Andrew Sullivan、DIN Darshak Thakore、CableLabs Dave Thaler、Microsoft Hannes Tschofenig、ARM Limited Michael Verschoor、飞利浦照明
IAB Members at the Time of Approval
批准时的IAB成员
Jari Arkko Alissa Cooper Ted Hardie Christian Huitema Gabriel Montenegro Erik Nordmark Mark Nottingham Melinda Shore Robert Sparks Jeff Tantsura Martin Thomson Brian Trammell Suzanne Woolf
雅丽·阿尔科·艾莉莎·库珀·泰德·哈迪·克里斯蒂安·惠特玛·加布里埃尔·黑山埃里克·诺德马克·马克·诺丁汉·梅林达海岸罗伯特·斯帕克斯·杰夫·坦特拉·马丁·汤姆森·布莱恩·特拉梅尔·苏珊娜·伍尔夫
Acknowledgements
致谢
We would like to thank all paper authors and participants for their contributions and Ericsson for hosting the workshop.
我们要感谢所有论文作者和参与者的贡献，并感谢爱立信主办研讨会。
Authors' Addresses
作者地址
Jaime Jimenez
杰米·希门尼斯
Email: jaime.jimenez@ericsson.com
Email: jaime.jimenez@ericsson.com
Hannes Tschofenig
汉内斯·乔菲尼
Email: hannes.tschofenig@arm.com
Email: hannes.tschofenig@arm.com
Dave Thaler
戴夫·泰勒
Email: dthaler@microsoft.com
Email: dthaler@microsoft.com