[要約] RFC 7452は、スマートオブジェクトネットワーキングにおけるアーキテクチャの考慮事項に関するドキュメントです。このRFCの目的は、スマートオブジェクトネットワーキングの設計と展開において、アーキテクチャ上の問題や課題を理解し、解決策を提供することです。
Internet Architecture Board (IAB) H. Tschofenig
Request for Comments: 7452 ARM Ltd.
Category: Informational J. Arkko
ISSN: 2070-1721 D. Thaler
D. McPherson
March 2015
Architectural Considerations in Smart Object Networking
スマートオブジェクトネットワーキングのアーキテクチャに関する考慮事項
Abstract
概要
The term "Internet of Things" (IoT) denotes a trend where a large number of embedded devices employ communication services offered by Internet protocols. Many of these devices, often called "smart objects", are not directly operated by humans but exist as components in buildings or vehicles, or are spread out in the environment. Following the theme "Everything that can be connected will be connected", engineers and researchers designing smart object networks need to decide how to achieve this in practice.
「モノのインターネット」（IoT）という用語は、多数の組み込みデバイスがインターネットプロトコルによって提供される通信サービスを採用する傾向を示しています。これらのデバイスの多くは、しばしば「スマートオブジェクト」と呼ばれ、人間が直接操作するのではなく、建物や車両のコンポーネントとして存在するか、環境内に広がっています。 「接続できるものはすべて接続される」というテーマに従って、スマートオブジェクトネットワークを設計するエンジニアや研究者は、実際にこれを実現する方法を決定する必要があります。
This document offers guidance to engineers designing Internet-connected smart objects.
このドキュメントは、インターネットに接続されたスマートオブジェクトを設計するエンジニアにガイダンスを提供します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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 a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットアーキテクチャボード（IAB）の製品であり、IABが永続的な記録を提供するために価値があると見なした情報を表しています。これは、インターネットアーキテクチャボード（IAB）のコンセンサスを表しています。 IABによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc7452.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7452で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Smart Object Communication Patterns . . . . . . . . . . . . . 4
2.1. Device-to-Device Communication Pattern . . . . . . . . . 4
2.2. Device-to-Cloud Communication Pattern . . . . . . . . . . 6
2.3. Device-to-Gateway Communication Pattern . . . . . . . . . 7
2.4. Back-End Data Sharing Pattern . . . . . . . . . . . . . . 9
3. Reuse Internet Protocols . . . . . . . . . . . . . . . . . . 10
4. The Deployed Internet Matters . . . . . . . . . . . . . . . . 13
5. Design for Change . . . . . . . . . . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18
8. Informative References . . . . . . . . . . . . . . . . . . . 19
Appendix A. IAB Members at the Time of Approval . . . . . . . . 23
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
RFC 6574 [RFC6574] refers to smart objects as devices with constraints on energy, bandwidth, memory, size, cost, etc. This is a fuzzy definition, as there is clearly a continuum in device capabilities and there is no hard line to draw between devices that can run Internet protocols and those that can't.
RFC 6574 [RFC6574]は、エネルギー、帯域幅、メモリ、サイズ、コストなどに制約があるデバイスとしてスマートオブジェクトを参照します。これはあいまいな定義です。これは、デバイス機能に明確な連続性があり、間に線を引くことが難しいためです。インターネットプロトコルを実行できるデバイスと実行できないデバイス。
Interconnecting smart objects with the Internet enables exciting new use cases and products. An increasing number of products put the Internet Protocol Suite on smaller and smaller devices and offer the ability to process, visualize, and gain insight from the collected sensor data. The network effect can be increased if the data collected from many different devices can be combined.
スマートオブジェクトとインターネットを相互接続することで、エキサイティングな新しいユースケースと製品が可能になります。ますます多くの製品がインターネットプロトコルスイートをより小さなデバイスに搭載し、収集したセンサーデータから処理、視覚化、および洞察を得る機能を提供しています。多くの異なるデバイスから収集されたデータを組み合わせることができれば、ネットワークへの影響を増やすことができます。
Developing embedded systems is a complex task, and designers must make a number of design decisions such as:
組み込みシステムの開発は複雑な作業であり、設計者は次のような多くの設計上の決定を行わなければなりません。
o How long is the device designed to operate?
o デバイスは動作するように設計されていますか？
o How does it interact with the physical world? Is it a sensor or actuator or both?
o それは実際の世界とどのように相互作用しますか？センサーですか、アクチュエータですか？
o How many "owners" does it have? One? Many? Is the owner likely to change over the lifetime of the device?
o 「所有者」は何人ですか？ 1？たくさんの？所有者はデバイスの寿命の間に変わる可能性がありますか？
o Is it continuously or intermittently powered? Does it sleep?
o 継続的または断続的に電力が供給されますか？寝ますか？
o Is it connected to a network, and if so, how?
o ネットワークに接続されていますか？
o Will it be physically accessible for direct maintenance after deployment? How does that affect the security model?
o 配置後、直接メンテナンスのために物理的にアクセスできますか？それはセキュリティモデルにどのように影響しますか？
While developing embedded systems is itself a complex task, designing Internet-connected smart objects is even harder since it requires expertise with Internet protocols in addition to software programming and hardware skills. To simplify the development task, and thereby to lower the cost of developing new products and prototypes, we believe that reuse of prior work is essential. Therefore, we provide high-level guidance on the use of Internet technology for the development of smart objects, and connected systems in general.
組み込みシステムの開発自体は複雑な作業ですが、ソフトウェアプログラミングとハードウェアのスキルに加えてインターネットプロトコルに関する専門知識が必要であるため、インターネットに接続されたスマートオブジェクトの設計はさらに困難です。開発タスクを簡素化し、それによって新製品やプロトタイプの開発コストを削減するには、以前の作業の再利用が不可欠であると考えています。したがって、私たちは、スマートオブジェクトの開発のためのインターネット技術の使用、および一般的に接続されたシステムについて、高レベルのガイダンスを提供します。
Utilize Existing Design Patterns
既存のデザインパターンを利用する
Design patterns are generally reusable solutions to a commonly occurring design problem (see [Gamma] for more discussion). Existing smart object deployments show communication patterns that can be reused by engineers with the benefit of lowering the design effort. As discussed in the sections below, individual patterns also have an implication on the required interoperability between the different entities. Depending on the desired functionality, already-existing patterns can be reused and adjusted. Section 2 talks about various communication patterns.
デザインパターンは、一般的に発生するデザインの問題に対する再利用可能なソリューションです（詳細については、[ガンマ]を参照してください）。既存のスマートオブジェクトの展開は、エンジニアが再利用できる通信パターンを示しており、設計の労力を軽減できます。以下のセクションで説明するように、個々のパターンは、異なるエンティティ間で必要な相互運用性にも影響します。必要な機能に応じて、既存のパターンを再利用および調整できます。セクション2では、さまざまな通信パターンについて説明します。
Reuse Internet Protocols
インターネットプロトコルの再利用
Most smart object deployments can make use of the already-standardized Internet Protocol Suite. Internet protocols can be applied to almost any environment due to their generic design and typically offer plenty of potential for reconfiguration, which allows them to be tailored for the specific needs. Section 3 discusses this topic.
ほとんどのスマートオブジェクトの配置では、すでに標準化されているインターネットプロトコルスイートを利用できます。インターネットプロトコルは、その一般的な設計により、ほとんどすべての環境に適用でき、通常、再構成の可能性を十分に提供しており、特定のニーズに合わせて調整できます。セクション3では、このトピックについて説明します。
The Deployed Internet Matters
展開されたインターネットの問題
When connecting smart objects to the Internet, take existing deployment into consideration to avoid unpleasant surprises. Assuming an ideal, clean-slate deployment is, in many cases, far too optimistic since the already-deployed infrastructure is convenient to use. In Section 4, we highlight the importance of this topic.
スマートオブジェクトをインターネットに接続するときは、既存のデプロイメントを考慮して、不愉快な驚きを回避してください。理想的なクリーンスレートの展開を想定すると、多くの場合、すでに展開されているインフラストラクチャを使用するのに便利であるため、あまりにも楽観的です。セクション4では、このトピックの重要性を強調します。
Design for Change
変更のための設計
The Internet infrastructure, applications, and preferred building blocks evolve over time. Especially long-lived smart object deployments need to take this change into account, and Section 5 is dedicated to that topic.
インターネットインフラストラクチャ、アプリケーション、および推奨されるビルディングブロックは、時間とともに進化します。特に長寿命のスマートオブジェクトのデプロイメントでは、この変更を考慮に入れる必要があり、セクション5はそのトピックに特化しています。
This section illustrates a number of communication patterns utilized in the smart object environment. It is possible that more than one pattern can be applied at the same time in a product. Developers reusing those patterns will benefit from the experience of others as well as from documentation, source code, and available products.
このセクションでは、スマートオブジェクト環境で使用されるいくつかの通信パターンについて説明します。製品に複数のパターンを同時に適用できる場合があります。これらのパターンを再利用する開発者は、他のユーザーの経験だけでなく、ドキュメント、ソースコード、および利用可能な製品からもメリットを得られます。
Figure 1 illustrates a communication pattern where two devices developed by different manufacturers are desired to interoperate and communicate directly. To pick an example from [RFC6574], consider a light switch that talks to a light bulb with the requirement that each may be manufactured by a different company, represented as Manufacturer A and B. Other cases can be found with fitness equipment, such as heart rate monitors and cadence sensors.
図1は、異なるメーカーが開発した2つのデバイスが相互運用して直接通信することが望まれる通信パターンを示しています。 [RFC6574]から例を選択するために、それぞれがメーカーAおよびBとして表される別の会社によって製造される可能性があるという要件を持つ電球と通信するライトスイッチを検討してください。その他のケースは、フィットネス機器で見つけることができます。心拍数モニターとケイデンスセンサー。
_,,,, ,,,,
/ -'`` \
| Wireless |
\ Network |
/ \
,''''''''| / . ,''''''''|
| Light | ------|------------------\------| Light |
| Bulb | . | | Switch |
|........' `'- / |........'
\ _-...-`
Manufacturer `. ,.' Manufacturer
A ` B
Figure 1: Device-to-Device Communication Pattern
図1：デバイス間の通信パターン
In order to fulfill the promise that devices from different manufacturers are able to communicate out of the box, these vendors need to agree on the protocol stack. They need to make decisions about the following protocol-design aspects:
さまざまなメーカーのデバイスがそのまま通信できるという約束を果たすために、これらのベンダーはプロトコルスタックについて合意する必要があります。次のプロトコル設計の側面について決定を下す必要があります。
o Which physical layer(s) should be supported? Does it use low-power radio technologies (e.g., Bluetooth Smart, IEEE 802.15.4)?
o どの物理層をサポートする必要がありますか？低電力の無線技術（Bluetooth Smart、IEEE 802.15.4など）を使用していますか？
o Can devices be IPv6-only, or must they also support IPv4 for backward-compatibility reasons? What IPv4-IPv6 transition technologies are needed?
o デバイスをIPv6のみにすることはできますか、それとも下位互換性のためにIPv4もサポートする必要がありますか？どのIPv4-IPv6移行テクノロジが必要ですか？
o Which IP address configuration mechanism(s) is integrated into the device?
o どのIPアドレス構成メカニズムがデバイスに統合されていますか？
o Which communication architectures shall be supported? Which devices are constrained, and what are those constraints? Is there a classical client-server model or rather a peer-to-peer model?
o どの通信アーキテクチャがサポートされますか？制約されているデバイス、およびそれらの制約は何ですか？古典的なクライアントサーバーモデル、またはピアツーピアモデルはありますか？
o Is there a need for a service-discovery mechanism to allow users to discover light bulbs they have in their home or office?
o ユーザーが自宅やオフィスにある電球を発見できるようにするサービス発見メカニズムが必要ですか？
o Which transport-layer protocol (e.g., UDP) is used for conveying the sensor readings/commands?
o センサーの読み取り値/コマンドを伝達するために使用されるトランスポート層プロトコル（UDPなど）はどれですか？
o Which application-layer protocol is used (for example, the Constrained Application Protocol (CoAP) [RFC7252])?
o 使用されているアプリケーション層プロトコル（たとえば、制約付きアプリケーションプロトコル（CoAP）[RFC7252]）
o What information model is used for expressing the different light levels?
o さまざまな光レベルを表現するためにどの情報モデルが使用されますか？
o What data model is used to encode information? (See [RFC3444] for a discussion about the difference between data models and information models.)
o 情報のエンコードにはどのデータモデルが使用されますか？ （データモデルと情報モデルの違いについては、[RFC3444]を参照してください。）
o Finally, security and privacy require careful thought. This includes questions like: What are the security threats? What security services need to be provided to deal with the identified threats? Where do the security credentials come from? At what layer(s) in the protocol stack should the security mechanism(s) reside? What privacy implications are caused by various design decisions?
o 最後に、セキュリティとプライバシーは慎重に検討する必要があります。これには、次のような質問が含まれます。セキュリティの脅威は何ですか？特定された脅威に対処するには、どのセキュリティサービスを提供する必要がありますか？セキュリティ資格情報はどこから来ますか？セキュリティメカニズムは、プロトコルスタックのどのレイヤーに常駐する必要がありますか？さまざまな設計上の決定によって引き起こされるプライバシーの影響は何ですか？
This list is not meant to be exhaustive but aims to illustrate that for every usage scenario, many design decisions will have to be made in order to accommodate the constrained nature of a specific device in a certain usage scenario. Standardizing such a complete solution to accomplish a full level of interoperability between two devices manufactured by different vendors takes time, but there are obvious rewards for end customers and vendors.
このリストは完全なものではありませんが、すべての使用シナリオについて、特定の使用シナリオにおける特定のデバイスの制約された性質に対応するために、多くの設計決定を行う必要があることを示すことを目的としています。このような完全なソリューションを標準化して、異なるベンダーによって製造された2つのデバイス間の完全な相互運用性を実現するには時間がかかりますが、エンドカスタマーとベンダーには明らかな見返りがあります。
Figure 2 shows a communication pattern for uploading sensor data to an application service provider. Often the application service provider (example.com in our illustration) also sells smart objects. In that case, the entire communication happens internal to the provider and no need for interoperability arises. Still, it is useful for example.com to reuse existing specifications to lower the design, implementation, testing, and development effort.
図2は、センサーデータをアプリケーションサービスプロバイダーにアップロードするための通信パターンを示しています。多くの場合、アプリケーションサービスプロバイダー（この図ではexample.com）もスマートオブジェクトを販売しています。その場合、通信全体がプロバイダー内部で行われるため、相互運用性は必要ありません。それでも、example.comが既存の仕様を再利用して、設計、実装、テスト、および開発の労力を軽減することは有用です。
While this pattern allows using IP-based communication end to end, it may still lead to silos. To prevent silos, example.com may allow third-party device vendors to connect to their server infrastructure as well. For those cases, the protocol interface used to communicate with the server infrastructure needs to be made available, and various standards are available, such as CoAP, Datagram Transport Layer Security (DTLS) [RFC6347], UDP, IP, etc., as shown in Figure 2. A frequent concern from end users is that a change in the business model (or bankruptcy) of the IoT device/service provide might make the hardware become unusable. Companies might consider the possibility of releasing their source code for the IoT device or allowing other IoT operating systems (plus application software) to be installed on the IoT device.
このパターンではエンドツーエンドでIPベースの通信を使用できますが、サイロが発生する可能性があります。サイロを防ぐために、example.comはサードパーティのデバイスベンダーがサーバーインフラストラクチャに接続することも許可する場合があります。これらのケースでは、サーバーインフラストラクチャとの通信に使用されるプロトコルインターフェイスを使用可能にする必要があり、CoAP、データグラムトランスポート層セキュリティ（DTLS）[RFC6347]、UDP、IPなど、さまざまな標準を使用できます。図2を参照してください。エンドユーザーからの頻繁な懸念は、IoTデバイス/サービスのビジネスモデル（または破産）の変更により、ハードウェアが使用できなくなる可能性があることです。企業は、IoTデバイスのソースコードをリリースしたり、他のIoTオペレーティングシステム（およびアプリケーションソフトウェア）をIoTデバイスにインストールできるようにすることを検討する場合があります。
Similarly, in many situations it is desirable to change which cloud service a device connects to, such as when an application service provider changes its hosting provider. Again, standard Internet protocols are needed.
同様に、アプリケーションサービスプロバイダーがホスティングプロバイダーを変更する場合など、多くの状況では、デバイスが接続するクラウドサービスを変更することが望まれます。ここでも、標準のインターネットプロトコルが必要です。
Since the access networks to which various smart objects are connected are typically not under the control of the application service provider, commonly used radio technologies (such as WLAN, wired Ethernet, and cellular radio) together with the network access authentication technology have to be reused. The same applies to standards used for IP address configuration.
さまざまなスマートオブジェクトが接続されているアクセスネットワークは、通常、アプリケーションサービスプロバイダーの管理下にないため、一般的に使用される無線技術（WLAN、有線イーサネット、セルラー無線など）とネットワークアクセス認証技術を併用する必要があります。 。同じことは、IPアドレス構成に使用される標準にも当てはまります。
.................
| Application |
| Service |
| Provider |
| example.com |
|_______________|
_, .
HTTP ,' `. CoAP
TLS _,' `. DTLS
TCP ,' `._ UDP
IP -' - IP
,'''''''''''''| ,'''''''''''''''''|
| Device with | | Device with |
| Temperature | | Carbon Monoxide |
| Sensor | | Sensor |
|.............' |.................'
TLS = Transport Layer Security
Figure 2: Device-to-Cloud Communication Pattern
図2：デバイスからクラウドへの通信パターン
The device-to-cloud communication pattern, described in Section 2.2, is convenient for vendors of smart objects and works well if they choose a radio technology that is widely deployed in the targeted market, such as Wi-Fi based on IEEE 802.11 for smart home use cases. Sometimes, less-widely-available radio technologies are needed (such as IEEE 802.15.4) or special application-layer functionality (e.g., local authentication and authorization) has to be provided or interoperability is needed with legacy, non-IP-based devices. In those cases, some form of gateway has to be introduced into the communication architecture that bridges between the different technologies and performs other networking and security functionality. Figure 3 shows this pattern graphically. Often, these gateways are provided by the same vendor that offers the IoT product, for example, because of the use of proprietary protocols, to lower the dependency on other vendors or to avoid potential interoperability problems. It is expected that in the future, more generic gateways will be deployed to lower cost and infrastructure complexity for end consumers, enterprises, and industrial environments. Such generic gateways are more likely to exist if IoT device designs make use of generic Internet protocols and not require application-layer gateways that translate one application-layer protocol to another one. The use of application-layer gateways will, in general, lead to a more fragile deployment, as has been observed in the past with [RFC3724] and [RFC3238].
セクション2.2で説明するデバイスからクラウドへの通信パターンは、スマートオブジェクトのベンダーにとって便利であり、スマート向けのIEEE 802.11に基づくWi-Fiなど、対象市場で広く展開されている無線技術を選択した場合にうまく機能します家の使用例。時々、それほど広く利用できない無線技術（IEEE 802.15.4など）が必要であるか、特別なアプリケーション層機能（たとえば、ローカル認証および承認）を提供する必要があるか、レガシーの非IPベースのデバイスとの相互運用性が必要です。そのような場合、さまざまなテクノロジー間を橋渡しし、他のネットワーキングおよびセキュリティ機能を実行する何らかの形式のゲートウェイを通信アーキテクチャに導入する必要があります。図3は、このパターンをグラフで示しています。多くの場合、これらのゲートウェイは、他のベンダーへの依存を減らしたり、潜在的な相互運用性の問題を回避したりするために、独自仕様のプロトコルを使用しているなどの理由で、IoT製品を提供する同じベンダーによって提供されます。将来的には、より一般的なゲートウェイが展開され、エンドコンシューマ、企業、および産業環境のコストとインフラストラクチャの複雑さを低減することが期待されています。このような一般的なゲートウェイは、IoTデバイスの設計が一般的なインターネットプロトコルを利用し、1つのアプリケーション層プロトコルを別のプロトコルに変換するアプリケーション層ゲートウェイを必要としない場合に存在する可能性が高くなります。 [RFC3724]と[RFC3238]で過去に観察されたように、アプリケーション層ゲートウェイを使用すると、一般に、より脆弱な展開が行われます。
This communication pattern can frequently be found with smart object deployments that require remote configuration capabilities and real-time interactions. The gateway is thereby assumed to be always connected to the Internet.
この通信パターンは、リモート構成機能とリアルタイムの対話を必要とするスマートオブジェクトのデプロイメントでよく見られます。これにより、ゲートウェイは常にインターネットに接続されていると想定されます。
.................
| Application |
| Service |
| Provider |
| example.com |
|_______________|
|
|
| IPv4/IPv6
.................
| Local |
| Gateway |
| |
|_______________|
_, .
HTTP ,' `. CoAP
TLS _,' Bluetooth Smart `. DTLS
TCP ,' IEEE 802.11 `._ UDP
IPv6 -' IEEE 802.15.4 - IPv6
,'''''''''''''| ,'''''''''''''''''|
| Device with | | Device with |
| Temperature | | Carbon Monoxide |
| Sensor | | Sensor |
|.............' |.................'
Figure 3: Device-to-Gateway Communication Pattern
図3：デバイスからゲートウェイへの通信パターン
If the gateway is mobile, such as when the gateway is a smartphone, connectivity between the devices and the Internet may be intermittent. This limits the applicability of such a communication pattern but is nevertheless very common with wearables and other IoT devices that do not need always-on Internet or real-time Internet connectivity. From an interoperability point of view, it is worth noting that smartphones, with their sophisticated software update mechanism via app stores, allow new functionality to be updated regularly at the smartphone and sometimes even at the IoT device. With special apps that are tailored to each specific IoT device, interoperability is mainly a concern with regard to the lower layers of the protocol stack, such as the radio interface, and less so at the application layer (if users are willing to download a new app for each IoT device).
ゲートウェイがスマートフォンの場合など、ゲートウェイがモバイルの場合、デバイスとインターネット間の接続が断続的になる可能性があります。これは、そのような通信パターンの適用性を制限しますが、それでも、常時接続のインターネットまたはリアルタイムのインターネット接続を必要としないウェアラブルやその他のIoTデバイスでは非常に一般的です。相互運用性の観点から見ると、アプリストアを介した高度なソフトウェア更新メカニズムを備えたスマートフォンは、スマートフォンで、また場合によってはIoTデバイスでさえ、新機能を定期的に更新できることに注意する価値があります。特定の各IoTデバイスに合わせて調整された特別なアプリの場合、相互運用性は主に、無線インターフェースなどのプロトコルスタックの下位層に関する問題であり、アプリケーション層ではそれほど問題ではありません（ユーザーが新しい各IoTデバイスのアプリ）。
It is also worth pointing out that a gateway allows supporting both IPv6 and IPv4 (for compatibility with legacy application service providers) externally, while allowing devices to be IPv6-only to reduce footprint requirements. If devices do not have the resources to support both IPv4 and IPv6 themselves, being IPv6-only (rather than IPv4-only) with a gateway enables the most flexibility, avoiding the need to update devices to support IPv6 later, whereas IPv4 address exhaustion makes it ill-suited to scale to smart object networks. See [RFC6540] for further discussion.
また、ゲートウェイはIPv6とIPv4の両方を（レガシーアプリケーションサービスプロバイダーとの互換性のために）外部でサポートできる一方で、デバイスをIPv6のみにしてフットプリント要件を削減できることも指摘する価値があります。デバイスにIPv4とIPv6の両方をサポートするリソースがない場合、ゲートウェイをIPv6のみ（IPv4のみではなく）にすることで最も柔軟性が高まり、後でIPv6をサポートするようにデバイスを更新する必要がなくなりますが、IPv4アドレスの枯渇により、スマートオブジェクトネットワークへの拡張には適していません。詳細については、[RFC6540]を参照してください。
The device-to-cloud pattern often leads to silos; IoT devices upload data only to a single application service provider. However, users often demand the ability to export and to analyze data in combination with data from other sources. Hence, the desire for granting access to the uploaded sensor data to third parties arises. This design is shown in Figure 4. This pattern is known from the Web in case of mashups and is, therefore, reapplied to the smart object context. To offer familiarity for developers, typically a RESTful API design in combination with a federated authentication and authorization technology (like OAuth 2.0 [RFC6749]) is reused. While this offers reuse at the level of building blocks, the entire protocol stack (including the information/data model and RESTful Web APIs) is often not standardized.
デバイスからクラウドへのパターンは、多くの場合、サイロにつながります。 IoTデバイスは、単一のアプリケーションサービスプロバイダーにのみデータをアップロードします。ただし、ユーザーは多くの場合、他のソースからのデータと組み合わせてデータをエクスポートおよび分析する機能を要求します。したがって、アップロードされたセンサーデータへのアクセスを第三者に許可したいという要望が生じます。この設計を図4に示します。このパターンは、マッシュアップの場合はWebから認識されるため、スマートオブジェクトコンテキストに再適用されます。開発者に親しみやすさを提供するために、通常、RESTful API設計はフェデレーテッド認証および許可テクノロジー（OAuth 2.0 [RFC6749]など）と組み合わせて再利用されます。これはビルディングブロックのレベルでの再利用を提供しますが、プロトコルスタック全体（情報/データモデルおよびRESTful Web APIを含む）は標準化されていないことがよくあります。
.................
| Application |
.| Service |
,-` | Provider |
.` | b-example.com |
,-` |_______________|
.`
................. ,-`
| Application |-` HTTPS
| Service | OAuth 2.0
| Provider | JSON
| example.com |-,
|_______________| '.
_, `',
,' '.
_,' CoAP or `', .................
,' HTTP '. | Application |
-' `'| Service |
,''''''''| | Provider |
| Light | | c-example.com |
| Sensor | |_______________|
|........'
Figure 4: Back-End Data Sharing Pattern
図4：バックエンドデータ共有パターン
When discussing the need for reuse of available standards versus extending or redesigning protocols, it is useful to look back at the criteria for success of the Internet.
プロトコルの拡張や再設計ではなく、利用可能な標準の再利用の必要性について議論するとき、インターネットの成功基準を振り返ってみると役立ちます。
RFC 1958 [RFC1958] provides lessons from the early days of the Internet and says:
RFC 1958 [RFC1958]は、インターネットの初期の時代からの教訓を提供し、次のように述べています。
The Internet and its architecture have grown in evolutionary fashion from modest beginnings, rather than from a Grand Plan.
インターネットとそのアーキテクチャは、グランドプランからではなく、ささやかな始まりから進化的な方法で成長しています。
And adds:
そして追加：
A good analogy for the development of the Internet is that of constantly renewing the individual streets and buildings of a city, rather than razing the city and rebuilding it.
インターネットの開発の良い例えは、都市を破壊して再構築するのではなく、都市の個々の道路や建物を常に更新することです。
Yet, because building very small, battery-powered devices is challenging, it may be difficult to resist the temptation to build solutions tailored to specific applications, or even to redesign networks from scratch to suit a particular application.
しかし、非常に小型のバッテリ駆動のデバイスを構築することは困難であるため、特定のアプリケーションに合わせたソリューションを構築したり、特定のアプリケーションに合わせてネットワークをゼロから再設計したりする誘惑に抵抗することは難しい場合があります。
While developing consensus-based standards in an open and transparent process takes longer than developing proprietary solutions, the resulting solutions often remain relevant over a longer period of time.
オープンで透過的なプロセスでコンセンサスベースの標準を開発することは、独自のソリューションを開発するよりも時間がかかりますが、結果として得られるソリューションは多くの場合、長期間にわたって関連性を保ちます。
RFC 1263 [RFC1263] considers protocol-design strategy and the decision to design new protocols or to use existing protocols in a non-backward compatible way:
RFC 1263 [RFC1263]は、プロトコル設計戦略と、新しいプロトコルを設計するか、既存のプロトコルを下位互換性のない方法で使用するかを決定します。
We hope to be able to design and distribute protocols in less time than it takes a standards committee to agree on an acceptable meeting time. This is inevitable because the basic problem with networking is the standardization process. Over the last several years, there has been a push in the research community for lightweight protocols, when in fact what is needed are lightweight standards. Also note that we have not proposed to implement some entirely new set of 'superior' communications protocols, we have simply proposed a system for making necessary changes to the existing protocol suites fast enough to keep up with the underlying change in the network. In fact, the first standards organization that realizes that the primary impediment to standardization is poor logistical support will probably win.
標準委員会が許容できる会議時間について合意するのにかかる時間よりも短い時間でプロトコルを設計および配布できることを願っています。ネットワーキングの基本的な問題は標準化プロセスであるため、これは避けられません。過去数年にわたって、実際に必要なのは軽量規格であるのに、軽量コミュニティの研究コミュニティでの推進がありました。また、まったく新しい「優れた」通信プロトコルのセットを実装することを提案していないことにも注意してください。既存のプロトコルスイートに必要な変更を、ネットワークの根本的な変化に追いつくのに十分な速さで行うシステムを提案しただけです。実際、標準化の主な障害は貧弱な後方支援であることを認識した最初の標準化組織がおそらく勝利するでしょう。
While [RFC1263] was written in 1991 when the standardization process was more lightweight than today, these thoughts remain relevant in smart object development.
[RFC1263]は、標準化プロセスが今日よりも軽量化された1991年に書かれましたが、これらの考え方はスマートオブジェクトの開発にも関連しています。
Interestingly, a large number of already-standardized protocols are relevant for smart object deployments. RFC 6272 [RFC6272], for example, made the attempt to identify relevant IETF specifications for use in smart grids.
興味深いことに、すでに標準化されている多数のプロトコルがスマートオブジェクトの展開に関連しています。たとえば、RFC 6272 [RFC6272]は、スマートグリッドで使用するための関連するIETF仕様を特定しようとしました。
Still, many commercial products contain proprietary or industry-specific protocol mechanisms, and researchers have made several attempts to design new architectures for the entire Internet system. There are several architectural concerns that deserve to be highlighted:
それでも、多くの市販製品には独自仕様または業界固有のプロトコルメカニズムが含まれており、研究者はインターネットシステム全体の新しいアーキテクチャを設計するためにいくつかの試みを行っています。強調するに値するいくつかのアーキテクチャ上の懸念があります：
Vertical Profiles
垂直プロファイル
The discussions at the IAB workshop (see Section 3.1.2 of [RFC6574]) revealed the preference of many participants to develop domain-specific profiles that select a minimum subset of protocols needed for a specific operating environment. Various standardization organizations and industry fora are currently engaged in activities of defining their preferred profile(s).
IABワークショップでの議論（[RFC6574]のセクション3.1.2を参照）により、特定の運用環境に必要なプロトコルの最小サブセットを選択するドメイン固有のプロファイルを開発する多くの参加者の好みが明らかになりました。現在、さまざまな標準化組織や業界フォーラムが、それぞれの望ましいプロファイルを定義する活動に従事しています。
Ultimately, however, the number of domains where smart objects can be used is essentially unbounded. There is also an ever-evolving set of protocols and protocol extensions.
ただし、最終的には、スマートオブジェクトを使用できるドメインの数は基本的に無制限です。また、プロトコルとプロトコル拡張のセットは常に進化しています。
However, merely changing the networking protocol to IP does not necessarily bring the kinds of benefits that industries are looking for in their evolving smart object deployments. In particular, a profile is rigid and leaves little room for interoperability among slightly differing or competing technology variations. As an example, Layer 1 through 7 type profiles do not account for the possibility that some devices may use different physical media than others, and that in such situations, a simple router could still provide an ability to communicate between the parties.
ただし、ネットワークプロトコルを単にIPに変更するだけでは、進化するスマートオブジェクトの展開で業界が求めているような種類の利点が必ずしも得られるとは限りません。特に、プロファイルは固定されており、わずかに異なるまたは競合するテクノロジーのバリエーション間の相互運用性のための余地がほとんどありません。例として、レイヤ1〜7タイプのプロファイルは、一部のデバイスが他のデバイスとは異なる物理メディアを使用する可能性、およびそのような状況でも、単純なルーターがパーティ間で通信する機能を提供する可能性を考慮していません。
Industry-Specific Solutions
業界固有のソリューション
The Internet Protocol Suite is more extensive than merely the use of IP. Often, significant benefits can be gained from using additional, widely available, generic technologies, such as the Web. Benefits from using these kinds of tools include access to a large available workforce, software, and education already geared towards employing the technology.
インターネットプロトコルスイートは、単なるIPの使用よりも広範なものです。多くの場合、Webなどの追加の広く利用可能な汎用テクノロジを使用することで、大きなメリットが得られます。これらの種類のツールを使用することの利点には、利用可能な大規模な労働力、ソフトウェア、およびテクノロジーの採用に向けた教育へのアクセスが含まれます。
Tight Coupling
密結合
Many applications are built around a specific set of servers, devices, and users. However, often the same data and devices could be useful for many purposes, some of which may not be easily identifiable at the time the devices are deployed.
多くのアプリケーションは、特定のサーバー、デバイス、ユーザーのセットを中心に構築されています。ただし、多くの場合、同じデータとデバイスが多くの目的に役立つ可能性があり、その一部はデバイスの展開時に簡単に識別できない場合があります。
In addition to the architectural concerns, developing new protocols and mechanisms is generally more risky and expensive than reusing existing standards, due to the additional costs involved in design, implementation, testing, and deployment. Secondary costs, such as the training of technical staff and, in the worst case, the training of end users, can be substantial.
アーキテクチャ上の問題に加えて、新しいプロトコルとメカニズムの開発は、設計、実装、テスト、および展開にかかる追加コストのため、既存の標準を再利用するよりも一般にリスクが高く、費用がかかります。技術スタッフのトレーニングや、最悪の場合、エンドユーザーのトレーニングなどの二次コストは、かなりの額になる可能性があります。
As a result, while there are some cases where specific solutions are needed, the benefits of general-purpose technology are often compelling, be it choosing IP over some more specific communication mechanism, a widely deployed link layer (such as wireless LAN) over a more specific one, web technology over application-specific protocols, and so on.
その結果、特定のソリューションが必要となる場合もありますが、汎用テクノロジーの利点は、特定の通信メカニズムやIPを介して広く展開されているリンクレイヤー（無線LANなど）を介してIPを選択する場合など、多くの場合説得力があります。より具体的なもの、アプリケーション固有のプロトコルを介したWebテクノロジーなど。
However, when employing these technologies, it is important to embrace them in their entirety, allowing for the architectural flexibility that is built into them. As an example, it rarely makes sense to limit communications to on-link or to specific media. Design your applications so that the participating devices can easily interact with multiple other applications.
ただし、これらのテクノロジーを採用する場合は、それらを完全に取り入れて、それらに組み込まれているアーキテクチャの柔軟性を可能にすることが重要です。例として、通信をオンリンクまたは特定のメディアに制限することはほとんど意味がありません。参加しているデバイスが他の複数のアプリケーションと簡単に対話できるようにアプリケーションを設計します。
Despite the applicability of Internet protocols for smart objects, picking the specific protocols for a particular use case can be tricky. As the Internet has evolved, certain protocols and protocol extensions have become the norm, and others have become difficult to use in all circumstances.
スマートオブジェクトに対するインターネットプロトコルの適用性にもかかわらず、特定のユースケースに特定のプロトコルを選択するのは難しい場合があります。インターネットの進化に伴い、特定のプロトコルとプロトコル拡張が標準になり、その他のプロトコルはすべての状況で使用することが困難になりました。
Taking into account these constraints is particularly important for smart objects, as there is often a desire to employ specific features to support smart object communication. For instance, from a pure protocol-specification perspective, some transport protocols may be more desirable than others. These constraints apply both to the use of existing protocols as well as designing new ones on top of the Internet protocol stack.
スマートオブジェクトの通信をサポートするために特定の機能を採用したい場合が多いため、これらの制約を考慮することはスマートオブジェクトにとって特に重要です。たとえば、純粋なプロトコル仕様の観点から、一部のトランスポートプロトコルは他のプロトコルよりも望ましい場合があります。これらの制約は、既存のプロトコルの使用だけでなく、インターネットプロトコルスタック上での新しいプロトコルの設計にも適用されます。
The following list illustrates a few of those constraints, but every communication protocol comes with its own challenges.
次のリストは、これらの制約のいくつかを示していますが、すべての通信プロトコルには独自の課題があります。
In 2005, Fonseca, et al. [IPoptions] studied the usage of IP options-enabled packets in the Internet and found that overall, approximately half of Internet paths drop packets with options, making extensions using IP options "less ideal" for extending IP.
2005年に、Fonsecaなど。 [IPoptions]は、インターネットでのIPオプション対応パケットの使用法を調査し、全体として、インターネットパスの約半分がオプション付きのパケットをドロップし、IPオプションを使用した拡張がIPの拡張に「あまり理想的でない」ことを発見しました。
In 2010, Honda, et al. [HomeGateway] tested 34 different home gateways regarding their packet dropping policy of UDP, TCP, the Datagram Congestion Control Protocol (DCCP), the Stream Control Transmission Protocol (SCTP), ICMP, and various timeout behavior. For example, more than half of the tested devices do not conform to the IETF-recommended timeouts for UDP, and for TCP the measured timeouts are highly variable, ranging from less than 4 minutes to longer than 25 hours. For NAT traversal of DCCP and SCTP, the situation is poor. None of the tested devices, for example, allowed establishing a DCCP connection.
2010年に、ホンダら。 [HomeGateway]は、UDP、TCP、データグラム輻輳制御プロトコル（DCCP）、ストリーム制御伝送プロトコル（SCTP）、ICMP、およびさまざまなタイムアウト動作のパケットドロップポリシーに関して、34の異なるホームゲートウェイをテストしました。たとえば、テストされたデバイスの半分以上は、UDPのIETF推奨タイムアウトに準拠しておらず、TCPの場合、測定されたタイムアウトは4分未満から25時間を超える範囲で非常に変動します。 DCCPおよびSCTPのNATトラバーサルの場合、状況は良くありません。たとえば、テストされたどのデバイスもDCCP接続の確立を許可していませんでした。
In 2011, the behavior of networks with regard to various TCP extensions was tested in [TCPextensions]: "From our results we conclude that the middleboxes implementing layer 4 functionality are very common -- at least 25% of paths interfered with TCP in some way beyond basic firewalling."
2011年に、さまざまなTCP拡張機能に関するネットワークの動作が[TCPextensions]でテストされました：「この結果から、レイヤー4機能を実装するミドルボックスは非常に一般的であると結論します-パスの少なくとも25％が何らかの方法でTCPに干渉しました基本的なファイアウォールを超えています。」
Extending protocols to fulfill new uses and to add new functionality may range from very easy to difficult, as [RFC6709] explains in great detail. A challenge many protocol designers are facing is to ensure incremental deployability and interoperability with incumbent elements in a number of areas. In various cases, the effort it takes to design incrementally deployable protocols has not been taken seriously enough at the outset. RFC 5218 on "What Makes For a Successful Protocol" [RFC5218] defines wildly successful protocols as protocols that are widely deployed beyond their envisioned use cases.
[RFC6709]で詳細に説明されているように、プロトコルを拡張して新しい用途を満たし、新しい機能を追加することは、非常に簡単なものから難しいものまでさまざまです。多くのプロトコル設計者が直面している課題は、多くの領域で既存の要素との段階的な展開可能性と相互運用性を確保することです。さまざまなケースで、段階的に展開可能なプロトコルを設計するために必要な作業は、最初は十分に真剣に行われていません。 RFC 5218の「成功するプロトコル」[RFC5218]は、非常に成功するプロトコルを、想定されるユースケースを超えて広く展開されているプロトコルとして定義しています。
As these examples illustrate, protocol architects have to take developments in the greater Internet into account, as not all features can be expected to be usable in all environments. For instance, middleboxes [RFC3234] complicate the use of extensions in basic IP protocols and transport layers.
これらの例が示すように、すべての機能がすべての環境で使用可能であると期待できるわけではないため、プロトコルアーキテクトは、インターネット全体の発展を考慮に入れる必要があります。たとえば、ミドルボックス[RFC3234]は、基本的なIPプロトコルとトランスポート層での拡張機能の使用を複雑にします。
RFC 1958 [RFC1958] considers this aspect and says "... the community believes that the goal is connectivity, the tool is the Internet Protocol, and the intelligence is end to end rather than hidden in the network." This statement is challenged more than ever with the perceived need to develop intermediaries interacting with less intelligent end devices. However, RFC 3724 [RFC3724] has this to say about this crucial aspect: "One desirable consequence of the end-to-end principle is protection of innovation. Requiring modification in the network in order to deploy new services is still typically more difficult than modifying end nodes." Even this statement will become challenged, as large numbers of devices are deployed, and it indeed might be the case that changing those devices will be hard. But RFC 4924 [RFC4924] adds that a network that does not filter or transform the data that it carries may be said to be "transparent" or "oblivious" to the content of packets. Networks that provide oblivious transport enable the deployment of new services without requiring changes to the core. It is this flexibility that is perhaps both the Internet's most essential characteristic as well as one of the most important contributors to its success.
RFC 1958 [RFC1958]はこの側面を考慮し、「コミュニティは、目標は接続性であり、ツールはインターネットプロトコルであり、インテリジェンスはネットワークに隠されているのではなく、エンドツーエンドであると信じています」と述べています。この声明は、知能の低いエンドデバイスと相互作用する仲介者を開発する必要性が認識されており、これまでになく挑戦されています。ただし、RFC 3724 [RFC3724]は、この重要な側面について次のように述べています。「エンドツーエンドの原則の望ましい結果の1つは、イノベーションの保護です。新しいサービスを展開するためにネットワークに変更を加えることは、通常、終了ノードを修正します。」多数のデバイスが展開されているため、このステートメントでさえ困難になり、実際、それらのデバイスの変更が困難になる場合があります。しかし、RFC 4924 [RFC4924]は、それが運ぶデータをフィルタリングまたは変換しないネットワークは、パケットのコンテンツに対して「透過的」または「気づかない」と言われる可能性があることを追加しています。気付かないトランスポートを提供するネットワークにより、コアに変更を加えることなく、新しいサービスを導入できます。この柔軟性は、おそらくインターネットの最も重要な特性であると同時に、その成功への最も重要な貢献者の1つでもあります。
How to embrace rapid innovation and at the same time accomplish a high level of interoperability is one of the key aspects for competing in the marketplace. RFC 1263 [RFC1263] points out that "protocol change happens and is currently happening at a very respectable clip...We simply propose [for engineers developing the technology] to explicitly deal with the changes rather [than] keep trying to hold back the flood."
急速な革新を受け入れ、同時に高いレベルの相互運用性を実現する方法は、市場で競争するための重要な側面の1つです。 RFC 1263 [RFC1263]は、「プロトコルの変更が発生し、現在は非常に立派なクリップで発生している...私たちは[テクノロジーを開発しているエンジニア向けに]変更を明示的に処理することを提案します。洪水。"
In [Tussles], Clark, et al. suggest to "design for variation in outcome, so that the outcome can be different in different places, and the tussle takes place within the design, not by distorting or violating it. Do not design so as to dictate the outcome. Rigid designs will be broken; designs that permit variation will flex under pressure and survive." The term "tussle" refers to the process whereby different parties, which are part of the Internet milieu and have interests that may be adverse to each other, adapt their mix of mechanisms to try to achieve their conflicting goals, and others respond by adapting the mechanisms to push back.
[Tussles]では、クラーク他。 「結果のバリエーションを設計することをお勧めします。その結果、結果は場所によって異なる可能性があり、乱闘は、それを変形または違反することによってではなく、設計内で発生します。結果を指示するように設計しないでください。壊れた;変動を許容する設計は圧力下で曲がって生き残るだろう。」 「乱闘」という用語は、インターネット環境の一部であり、互いに悪影響を及ぼす可能性のあるさまざまな当事者がメカニズムの組み合わせを調整して競合する目標を達成しようとするプロセスを指し、他のユーザーは押し戻すメカニズム。
In order to accomplish this, Clark, et al. suggest to:
これを達成するために、クラーク等。提案する：
1. Break complex systems into modular parts, so that one tussle does not spill over and distort unrelated issues.
1. 複雑なシステムをモジュール式の部品に分解し、1つの手間でこぼれたり、関連のない問題を歪めたりしないようにします。
2. Design for choice to permit the different players to express their preferences. Choice often requires open interfaces.
2. さまざまなプレーヤーが好みを表現できるように、選択のために設計します。多くの場合、選択にはオープンインターフェイスが必要です。
The main challenge with the suggested approach is predicting how conflicts among the different players will evolve. Since tussles evolve over time, there will be changes to the architecture, too. It is certainly difficult to pick the right set of building blocks and to develop a communication architecture that will last a long time, and many smart object deployments are envisioned to be rather long lived.
提案されたアプローチの主な課題は、さまざまなプレイヤー間の競合がどのように進展するかを予測することです。麻疹は時間とともに進化するため、アーキテクチャにも変更が加えられます。適切なビルディングブロックのセットを選択し、長持ちする通信アーキテクチャを開発することは確かに困難であり、多くのスマートオブジェクトのデプロイメントは長命であると想定されています。
Luckily, the design of the system does not need to be cast in stone during the design phase. It may adjust dynamically since many of the protocols allow for configurability and dynamic discovery. But, ultimately, software update mechanisms may provide the flexibility needed to deal with more substantial changes.
幸いなことに、システムの設計は、設計段階で石にキャストする必要はありません。多くのプロトコルが構成可能性と動的な発見を可能にするので、それは動的に調整するかもしれません。ただし、最終的には、ソフトウェア更新メカニズムにより、より大きな変更に対処するために必要な柔軟性が得られる場合があります。
A solid software update mechanism is needed not only for dealing with the changing Internet communication environment and for interoperability improvements but also for adding new features and for fixing security bugs. This approach may appear to be in conflict with classes of severely restricted devices since, in addition to a software update mechanism, spare flash and RAM capacity is needed. It is, however, a trade-off worth thinking about since better product support comes with a price.
変化するインターネット通信環境への対応や相互運用性の向上だけでなく、新機能の追加やセキュリティバグの修正のためにも、強固なソフトウェア更新メカニズムが必要です。この方法は、ソフトウェア更新メカニズムに加えて、予備のフラッシュとRAMの容量が必要になるため、厳しく制限されたデバイスのクラスと競合しているように見えることがあります。ただし、より優れた製品サポートには代償が伴うため、検討する価値があります。
As technology keeps advancing, the constraints that technology places on devices evolve as well. Microelectronics have become more capable as time goes by, often making it possible for new devices to be both less expensive and more capable than their predecessors. This trend can, however, be in some cases offset by the desire to embed communications technology in even smaller and cheaper objects. But it is important to design communications technology not just for today's constraints but also for tomorrow's. This is particularly important since the cost of a product is not only determined by the cost of hardware but also by the cost of not reusing already-available protocol stacks and software libraries by developing custom solutions.
テクノロジーが進歩し続けると、テクノロジーがデバイスに課す制約も進化します。マイクロエレクトロニクスは時間の経過とともに機能が向上し、多くの場合、新しいデバイスは以前のデバイスよりも安価で高機能になります。ただし、この傾向は、場合によっては、さらに小さくて安価なオブジェクトに通信技術を組み込むという要望によって相殺される場合があります。しかし、今日の制約だけでなく、明日の制約のためにも通信テクノロジーを設計することが重要です。製品のコストはハードウェアのコストだけでなく、カスタムソリューションを開発して既存のプロトコルスタックやソフトウェアライブラリを再利用しないコストによっても決まるため、これは特に重要です。
Software updates are common in operating systems and application programs today. Without them, most devices would pose a latent risk to the Internet at large. Arguably, the JavaScript-based web employs a very rapid software update mechanism with code being provided by many different parties (e.g., by websites loaded into the browser or by smartphone apps).
ソフトウェアの更新は、現在のオペレーティングシステムとアプリケーションプログラムでは一般的です。それらがなければ、ほとんどのデバイスはインターネット全体に潜在的なリスクをもたらします。間違いなく、JavaScriptベースのWebは、非常に迅速なソフトウェア更新メカニズムを採用しており、コードはさまざまな関係者（たとえば、ブラウザーに読み込まれたWebサイトやスマートフォンアプリによって）から提供されます。
Security is often even more important for smart objects than for more traditional computing systems, since interacting directly with the physical world can present greater dangers, and smart objects often operate autonomously without any human interaction for a long time period. The problem is compounded by the fact that there are often fewer resources available in constrained devices to actually implement security (e.g., see the discussion of "Class 0 devices" in Section 3 of [RFC7228]). As such, it is critical to design for security, taking into account a number of key considerations:
多くの場合、セキュリティはスマートオブジェクトの方が従来のコンピューティングシステムよりも重要です。物理的な世界と直接やり取りすることにより大きな危険が生じる可能性があり、スマートオブジェクトは多くの場合、人間の介入なしに長期間自律的に動作します。問題は、実際にセキュリティを実装するために制約されたデバイスで利用可能なリソースが少ないことが多いという事実によってさらに悪化します（たとえば、[RFC7228]のセクション3の「クラス0デバイス」の説明を参照してください）。そのため、いくつかの重要な考慮事項を考慮して、セキュリティを考慮して設計することが重要です。
o A key part of any smart object design is the problem of how to establish trust for a smart object. Typically, bootstrapping trust involves giving the device the credentials it needs to operate within a larger network of devices or services.
o スマートオブジェクト設計の重要な部分は、スマートオブジェクトの信頼を確立する方法の問題です。通常、信頼のブートストラップには、デバイスまたはサービスのより大きなネットワーク内で動作するために必要な資格情報をデバイスに与えることが含まれます。
o Smart objects will, in many cases, be deployed in places where additional physical security is difficult or impossible. Designers should take into account that any such device can and will be compromised by an attacker with direct physical access. Thus, trust models should distinguish between devices susceptible to physical compromise and devices with some level of physical security. Physical attacks, such as timing, power analysis, and glitching, are commonly applied to extract secrets [PhysicalAttacks].
o スマートオブジェクトは、多くの場合、追加の物理的セキュリティが困難または不可能である場所に展開されます。設計者は、このようなデバイスは物理的に直接アクセスできる攻撃者によって侵害される可能性があり、また侵害される可能性があることを考慮する必要があります。したがって、信頼モデルは、物理的な侵害の影響を受けやすいデバイスと、ある程度の物理的なセキュリティを備えたデバイスを区別する必要があります。タイミング、電力分析、グリッチなどの物理的な攻撃は、一般的に秘密を抽出するために適用されます[PhysicalAttacks]。
o Smart objects will, in many cases, be deployed as collections of identical or near identical devices. Protocols should be designed so that a compromise of a single device does not result in compromise of the entire collection, especially since the compromise of a large number of devices can enable additional attacks such as a distributed denial of service. Sharing secret keys across an entire product family is, therefore, also problematic since compromise of a single device might leave all devices from that product family vulnerable.
o スマートオブジェクトは、多くの場合、同一またはほぼ同一のデバイスのコレクションとして展開されます。特に、多数のデバイスの侵害が分散型サービス拒否などの追加の攻撃を可能にする可能性があるため、1つのデバイスの侵害がコレクション全体の侵害につながらないようにプロトコルを設計する必要があります。したがって、製品ファミリ全体で秘密鍵を共有すると、単一のデバイスが侵害されるとその製品ファミリのすべてのデバイスが脆弱になる可能性があるため、問題も発生します。
o Smart objects will, in many cases, be deployed in ways that the designer never considered. Designers should either seek to minimize the impact of misuse of their systems and devices or implement controls to prevent such misuse where applicable.
o スマートオブジェクトは、多くの場合、設計者が考慮しなかった方法で展開されます。設計者は、システムとデバイスの誤用による影響を最小限に抑えるか、該当する場合はそのような誤用を防ぐための制御を実装する必要があります。
o It is anticipated that smart objects will be deployed with a long (e.g., 5-40 years) life cycle. Any security mechanism chosen at the outset may not be "good enough" for the full lifespan of the device. Thus, long-lived devices should start with good security and provide a path to deploy new security mechanisms over the lifetime of the device.
o スマートオブジェクトは、長いライフサイクル（たとえば、5〜40年）で展開されることが予想されます。最初に選択したセキュリティメカニズムは、デバイスの全寿命に対して「十分」ではない場合があります。したがって、長寿命のデバイスは、優れたセキュリティで開始し、デバイスの寿命にわたって新しいセキュリティメカニズムを展開するためのパスを提供する必要があります。
o Security protocols often rely on random numbers, and offering randomness in embedded devices is challenging. For this reason, it is important to consider the use of hardware-based random number generators during early states of the design process.
o セキュリティプロトコルは乱数に依存することが多く、組み込みデバイスでランダム性を提供することは困難です。このため、設計プロセスの初期段階では、ハードウェアベースの乱数ジェネレータの使用を検討することが重要です。
A more detailed security discussion can be found in the "Report from the Smart Object Security Workshop" [RFC7397] that was held prior to the IETF meeting in Paris, March 2012, and in the report from the National Science Foundation's "Cybersecurity Ideas Lab" workshop [NSF] that was held in February 2014. For example, [NSF] includes, among other recommendations, these recommendations specific to the Internet of Things:
より詳細なセキュリティの議論は、2012年3月にパリでIETF会議の前に開催された「スマートオブジェクトセキュリティワークショップからのレポート」[RFC7397]、および全米科学財団の「サイバーセキュリティアイデアラボ」からのレポートにあります。 2014年2月に開催されたワークショップ[NSF]。たとえば、[NSF]には、特に、モノのインターネットに固有の次の推奨事項が含まれています。
Enhance the Security of the Internet of Things by Identifying Enclaves: The security challenges posed by the emerging Internet of Things should be addressed now, to prepare before it is fully upon us. By identifying specific use segments, or "enclaves", Internet of Things infrastructure stakeholders can address the security requirements and devise event remediations for that enclave.
エンクレーブを特定してモノのインターネットのセキュリティを強化する：モノのインターネットが出現する前に準備するために、新たなモノのインターネットによってもたらされるセキュリティの課題に今すぐ対処する必要があります。特定の使用セグメント、つまり「エンクレーブ」を特定することにより、モノのインターネットインフラストラクチャの関係者は、セキュリティ要件に対応し、そのエンクレーブのイベント修正を考案できます。
Create a Framework for Managing Software Updates: The Internet of Things will challenge our current channels for distributing security updates. An environment must be developed for distributing security patches that scales to a world where almost everything is connected to the Internet and many "things" are largely unattended.
ソフトウェアの更新を管理するためのフレームワークを作成する：モノのインターネットは、セキュリティの更新を配布するための現在のチャネルに挑戦します。ほとんどすべてがインターネットに接続され、多くの「もの」がほとんど無人である世界に対応するセキュリティパッチを配布するための環境を開発する必要があります。
Finally, we reiterate that use of standards that have gotten wide review can often avoid a number of security issues that could otherwise arise. Section 3.3 of [RFC6574] reminds us about the IETF work style regarding security:
最後に、広くレビューされた標準を使用すると、通常は発生する可能性のある多くのセキュリティ問題を回避できることを繰り返します。 [RFC6574]のセクション3.3は、セキュリティに関するIETFのワークスタイルについて思い出させてくれます。
In the development of smart object applications, as with any other protocol application solution, security has to be considered early in the design process. As such, the recommendations currently provided to IETF protocol architects, such as RFC 3552 [RFC3552], and RFC 4101 [RFC4101], apply also to the smart object space.
スマートオブジェクトアプリケーションの開発では、他のプロトコルアプリケーションソリューションと同様に、設計プロセスの早い段階でセキュリティを考慮する必要があります。そのため、現在RFC 3552 [RFC3552]やRFC 4101 [RFC4101]などのIETFプロトコルアーキテクトに提供されている推奨事項は、スマートオブジェクトスペースにも適用されます。
In the IETF, security functionality is incorporated into each protocol as appropriate, to deal with threats that are specific to them. It is extremely unlikely that there is a one-size-fits-all security solution given the large number of choices for the 'right' protocol architecture (particularly at the application layer). For this purpose, [RFC6272] offers a survey of IETF security mechanisms instead of suggesting a preferred one.
IETFでは、必要に応じてセキュリティ機能が各プロトコルに組み込まれ、特定の脅威に対処します。 「適切な」プロトコルアーキテクチャ（特にアプリケーション層）の選択肢が多数あることを考えると、万能のセキュリティソリューションが存在することはほとんどありません。この目的のために、[RFC6272]はIETFのセキュリティメカニズムの調査を提供しています。
This document mainly focuses on an engineering audience, i.e., those who are designing smart object protocols and architectures. Since there is no value-free design, privacy-related decisions also have to be made, even if they are just implicit in the reuse of certain technologies. RFC 6973 [RFC6973] and the threat model in [CONFIDENTIALITY] were written as guidance specifically for that audience and are also applicable to the smart object context.
このドキュメントは、主にエンジニアリングの対象者、つまりスマートオブジェクトのプロトコルとアーキテクチャを設計している対象者に焦点を当てています。価値のない設計がないため、特定のテクノロジーの再利用に暗黙的に含まれている場合でも、プライバシー関連の決定も行う必要があります。 RFC 6973 [RFC6973]および[CONFIDENTIALITY]の脅威モデルは、その対象ユーザー向けのガイダンスとして特別に作成され、スマートオブジェクトコンテキストにも適用できます。
For those looking at privacy from a deployment point of view, the following additional guidelines are suggested:
デプロイメントの観点からプライバシーを検討する場合は、以下の追加ガイドラインが推奨されます。
Transparency: Transparency of data collection and processing is key to avoid unpleasant surprises for owners and users of smart objects. Users and impacted parties must be put in a position to understand what items of personal data concerning them are collected and stored, as well for what purposes they are sought.
透明性：データ収集と処理の透明性は、スマートオブジェクトの所有者とユーザーにとって不愉快な驚きを避けるための鍵です。ユーザーと影響を受ける関係者は、ユーザーに関する個人データのどの項目が収集および保存されているか、またどのような目的で求められているかを理解できる立場にある必要があります。
Data Collection / Use Limitation: Smart objects should only store personal data that is adequate, relevant, and not excessive in relation to the purpose(s) for which they are processed. The use of anonymized data should be preferred wherever possible.
データの収集/使用制限：スマートオブジェクトは、適切で関連性があり、処理の目的に関連して過度ではない個人データのみを保存する必要があります。可能な限り、匿名化されたデータを使用することをお勧めします。
Data Access: Before deployment starts, it is necessary to consider who can access personal data collected by smart objects and under which conditions. Appropriate and clear procedures should be established in order to allow data subjects to properly exercise their rights.
データアクセス：展開を開始する前に、スマートオブジェクトによって収集された個人データに誰がどの条件でアクセスできるかを検討する必要があります。データ主体が適切に権利を行使できるようにするために、適切かつ明確な手順を確立する必要があります。
Data Security: Standardized data security measures to prevent unlawful access, alteration, or loss of smart object data need to be defined and deployed. Robust cryptographic techniques and proper authentication frameworks have to be used to limit the risk of unintended data transfers or unauthorized access.
データセキュリティ：スマートオブジェクトデータの不正アクセス、改ざん、または損失を防ぐための標準化されたデータセキュリティ対策を定義して展開する必要があります。堅牢な暗号化技術と適切な認証フレームワークを使用して、意図しないデータ転送や不正アクセスのリスクを制限する必要があります。
A more detailed treatment of privacy considerations that extend beyond engineering can be found in a publication from the Article 29 Working Party [WP223].
エンジニアリングを超えたプライバシーの考慮事項のより詳細な扱いは、第29条作業部会[WP223]の出版物に記載されています。
[CONFIDENTIALITY] Barnes, R., Schneier, B., Jennings, C., Hardie, T., Trammell, B., Huitema, C., and D. Borkmann, "Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement", Work in Progress, draft-iab-privsec-confidentiality-threat-04, March 2015.
[機密性] Barnes、R.、Schneier、B.、Jennings、C.、Hardie、T.、Trammell、B.、Huitema、C。、およびD. Borkmann、「広範にわたる監視に直面した場合の機密性：脅威モデルand Problem Statement」、Work in Progress、draft-iab-privsec-confidentiality-threat-04、2015年3月。
[Gamma] Gamma, E., "Design Patterns: Elements of Reusable Object-Oriented Software", 1995.
[ガンマ]ガンマ、E。、「設計パターン：再利用可能なオブジェクト指向ソフトウェアの要素」、1995年。
[HomeGateway] Eggert, L., "An Experimental Study of Home Gateway Characteristics", In Proceedings of the 10th annual Internet Measurement Conference, 2010, <http://eggert.org/papers/2010-imc-hgw-study.pdf>.
[HomeGateway] Eggert、L。、「ホームゲートウェイの特性の実験的研究」、第10回年次インターネット測定会議の議事録、2010年、<http://eggert.org/papers/2010-imc-hgw-study.pdf >。
[IPoptions] Fonseca, R., Porter, G., Katz, R., Shenker, S., and I. Stoica, "IP options are not an option", Technical Report UCB/EECS2005-24, 2005, <http://citeseer.ist.psu.edu/viewdoc/ summary?doi=10.1.1.123.4251>.
[IPoptions] Fonseca、R.、Porter、G.、Katz、R.、Shenker、S。、およびI. Stoica、「IPオプションはオプションではない」、テクニカルレポートUCB / EECS2005-24、2005、<http： //citeseer.ist.psu.edu/viewdoc/ summary？doi = 10.1.1.123.4251>。
[NSF] National Science Foundation, "Interdisciplinary Pathways towards a More Secure Internet", A report on the NSF-sponsored Cybersecurity Ideas Lab held in Arlington, Virginia, February 2014, <http://www.nsf.gov/cise/news/ CybersecurityIdeasLab_July2014.pdf>.
[NSF] National Science Foundation、「より安全なインターネットに向けた学際的経路」、NSFが後援するサイバーセキュリティアイデアラボに関するレポート、2014年2月、バージニア州アーリントンで開催、<http://www.nsf.gov/cise/news / CybersecurityIdeasLab_July2014.pdf>。
[PhysicalAttacks] Koeune, F. and F. Standaert, "A Tutorial on Physical Security and Side-Channel Attacks", in Foundations of Security Analysis and Design III: FOSAD 2004/2005 Tutorial Lectures; Lecture Notes in Computer Science, Vol. 3655, pp. 78-108, September 2005, <http://link.springer.com/chapter/10.1007%2F11554578_3>.
[PhysicalAttacks] Koeune、F。およびF. Standaert、「A Security Tutorial on Physical Security and Side-Channel Attacks」、Foundations of Security Analysis and Design III：FOSAD 2004/2005 Tutorial Lectures;コンピュータサイエンスの講義ノート、Vol。 3655、78-108ページ、2005年9月、<http://link.springer.com/chapter/10.1007%2F11554578_3>。
[RFC1263] O'Malley, S. and L. Peterson, "TCP Extensions Considered Harmful", RFC 1263, October 1991, <http://www.rfc-editor.org/info/rfc1263>.
[RFC1263] O'Malley、S。およびL. Peterson、「有害なTCP拡張機能」、RFC 1263、1991年10月、<http://www.rfc-editor.org/info/rfc1263>。
[RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996, <http://www.rfc-editor.org/info/rfc1958>.
[RFC1958] Carpenter、B。、「Architectural Principles of the Internet」、RFC 1958、June 1996、<http://www.rfc-editor.org/info/rfc1958>。
[RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002, <http://www.rfc-editor.org/info/rfc3234>.
[RFC3234] Carpenter、B。およびS. Brim、「Middleboxes：Taxonomy and Issues」、RFC 3234、2002年2月、<http://www.rfc-editor.org/info/rfc3234>。
[RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002, <http://www.rfc-editor.org/info/rfc3238>.
[RFC3238] Floyd、S。およびL. Daigle、「IAB Architectural and Policy Considerations for Open Pluggable Edge Services」、RFC 3238、2002年1月、<http://www.rfc-editor.org/info/rfc3238>。
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, January 2003, <http://www.rfc-editor.org/info/rfc3444>.
[RFC3444] Pras、A.およびJ. Schoenwaelder、「On the Difference between Information Models and Data Models」、RFC 3444、2003年1月、<http://www.rfc-editor.org/info/rfc3444>。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003, <http://www.rfc-editor.org/info/rfc3552>.
[RFC3552] Rescorla、E。およびB. Korver、「セキュリティに関する考慮事項に関するRFCテキストを作成するためのガイドライン」、BCP 72、RFC 3552、2003年7月、<http://www.rfc-editor.org/info/rfc3552>。
[RFC3724] Kempf, J., Austein, R., and IAB, "The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture", RFC 3724, March 2004, <http://www.rfc-editor.org/info/rfc3724>.
[RFC3724] Kempf、J.、Austein、R。、およびIAB、「中間層の台頭とエンドツーエンドの未来：インターネットアーキテクチャの進化に関する考察」、RFC 3724、2004年3月、<http ：//www.rfc-editor.org/info/rfc3724>。
[RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, June 2005, <http://www.rfc-editor.org/info/rfc4101>.
[RFC4101] Rescorla、E。およびIAB、「Writing Protocol Models」、RFC 4101、2005年6月、<http://www.rfc-editor.org/info/rfc4101>。
[RFC4924] Aboba, B. and E. Davies, "Reflections on Internet Transparency", RFC 4924, July 2007, <http://www.rfc-editor.org/info/rfc4924>.
[RFC4924] Aboba、B。およびE. Davies、「Reflections on Internet Transparency」、RFC 4924、2007年7月、<http://www.rfc-editor.org/info/rfc4924>。
[RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful Protocol?", RFC 5218, July 2008, <http://www.rfc-editor.org/info/rfc5218>.
[RFC5218]ターラー、D。およびB.アボバ、「成功するプロトコルを作るもの」、RFC 5218、2008年7月、<http://www.rfc-editor.org/info/rfc5218>。
[RFC6272] Baker, F. and D. Meyer, "Internet Protocols for the Smart Grid", RFC 6272, June 2011, <http://www.rfc-editor.org/info/rfc6272>.
[RFC6272]ベイカー、F。およびD.マイヤー、「スマートグリッドのためのインターネットプロトコル」、RFC 6272、2011年6月、<http://www.rfc-editor.org/info/rfc6272>。
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6347] Rescorla、E。およびN. Modadugu、「Datagram Transport Layer Security Version 1.2」、RFC 6347、2012年1月、<http://www.rfc-editor.org/info/rfc6347>。
[RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, "IPv6 Support Required for All IP-Capable Nodes", BCP 177, RFC 6540, April 2012, <http://www.rfc-editor.org/info/rfc6540>.
[RFC6540] George W.、Donley、C.、Liljenstolpe、C。、およびL. Howard、「すべてのIP対応ノードに必要なIPv6サポート」、BCP 177、RFC 6540、2012年4月、<http：// www .rfc-editor.org / info / rfc6540>。
[RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object Workshop", RFC 6574, April 2012, <http://www.rfc-editor.org/info/rfc6574>.
[RFC6574] Tschofenig、H。およびJ. Arkko、「Report from the Smart Object Workshop」、RFC 6574、2012年4月、<http://www.rfc-editor.org/info/rfc6574>。
[RFC6709] Carpenter, B., Aboba, B., and S. Cheshire, "Design Considerations for Protocol Extensions", RFC 6709, September 2012, <http://www.rfc-editor.org/info/rfc6709>.
[RFC6709] Carpenter、B.、Aboba、B。、およびS. Cheshire、「プロトコル拡張の設計上の考慮事項」、RFC 6709、2012年9月、<http://www.rfc-editor.org/info/rfc6709>。
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 6749, October 2012, <http://www.rfc-editor.org/info/rfc6749>.
[RFC6749] Hardt、D。、「The OAuth 2.0 Authorization Framework」、RFC 6749、2012年10月、<http://www.rfc-editor.org/info/rfc6749>。
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, July 2013, <http://www.rfc-editor.org/info/rfc6973>.
[RFC6973] Cooper、A.、Tschofenig、H.、Aboba、B.、Peterson、J.、Morris、J.、Hansen、M。、およびR. Smith、「インターネットプロトコルのプライバシーに関する考慮事項」、RFC 6973、7月2013、<http://www.rfc-editor.org/info/rfc6973>。
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, May 2014, <http://www.rfc-editor.org/info/rfc7228>.
[RFC7228] Bormann、C.、Ersue、M.、and A. Keranen、 "Terminology for Constrained-Node Networks"、RFC 7228、May 2014、<http://www.rfc-editor.org/info/rfc7228> 。
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, June 2014, <http://www.rfc-editor.org/info/rfc7252>.
[RFC7252] Shelby、Z.、Hartke、K。、およびC. Bormann、「The Constrained Application Protocol（CoAP）」、RFC 7252、2014年6月、<http://www.rfc-editor.org/info/rfc7252 >。
[RFC7397] Gilger, J. and H. Tschofenig, "Report from the Smart Object Security Workshop", RFC 7397, December 2014, <http://www.rfc-editor.org/info/rfc7397>.
[RFC7397] Gilger、J。およびH. Tschofenig、「スマートオブジェクトセキュリティワークショップからのレポート」、RFC 7397、2014年12月、<http://www.rfc-editor.org/info/rfc7397>。
[TCPextensions] Honda, M., Nishida, Y., Greenhalgh, A., Handley, M., and H. Tokuda, "Is it Still Possible to Extend TCP?", In Proceedings of the ACM Internet Measurement Conference (IMC), Berlin, Germany, November 2011, <http://conferences.sigcomm.org/imc/2011/docs/p181.pdf>.
[TCPextensions] Honda、M.、Nishida、Y.、Greenhalgh、A.、Handley、M。、およびH. Tokuda、「まだTCPを拡張することは可能ですか？」、ACMインターネット測定会議（IMC）の議事録、ドイツ、ベルリン、2011年11月、<http://conferences.sigcomm.org/imc/2011/docs/p181.pdf>。
[Tussles] Clark, D., Wroclawski, J., Sollins, K., and R. Braden, "Tussle in Cyberspace: Defining Tomorrow's Internet", In Proceedings of ACM SIGCOMM, 2002, <http://conferences.sigcomm.org/sigcomm/2002/papers/ tussle.html>.
[タッスル]クラークD.、ブロツラフJ.、ソリンズK.、およびR.ブレーデン、「サイバースペースの闘い：明日のインターネットの定義」、ACM SIGCOMMのプロシーディングス、2002年、<http：//conferences.sigcomm。 org / sigcomm / 2002 / papers / tussle.html>。
[WP223] Article 29 Data Protection Working Party, "Opinion 8/2014 on the Recent Developments on the Internet of Things", 14/ EN, WP 223, September 2014, <http://ec.europa.eu/justice/ data-protection/article-29/documentation/ opinion-recommendation/files/2014/wp223_en.pdf>.
[WP223]第29条データ保護作業部会、「モノのインターネットにおける最近の進展に関する意見8/2014」、14 / EN、WP 223、2014年9月、<http://ec.europa.eu/justice/ data -protection / article-29 / documentation / opinend-recommendation / files / 2014 / wp223_en.pdf>。
Jari Arkko Mary Barnes Marc Blanchet Joel Halpern Ted Hardie Joe Hildebrand Russ Housley Eliot Lear Xing Li Erik Nordmark Andrew Sullivan Dave Thaler Brian Trammell
ジャリアルコメアリーバーンズマークブランシェジョエルハルパーンテッドハーディジョーヒルデブランドラスハウズリーエリオットリアシンリーエリックノードマークアンドリューサリバンデイブターラーブライアントランメル
Acknowledgements
謝辞
We would like to thank the participants of the IAB Smart Object workshop for their input to the overall discussion about smart objects.
IABスマートオブジェクトワークショップの参加者に、スマートオブジェクトに関する全体的な議論への情報提供に感謝します。
Furthermore, we would like to thank Mike St. Johns, Jan Holler, Patrick Wetterwald, Atte Lansisalmi, Hannu Flinck, Bernard Aboba, Markku Tuohino, Wes George, Robert Sparks, S. Moonsesamy, Dave Crocker, and Steve Crocker in particular for their review comments.
さらに、Mike St. Johns、Jan Holler、Patrick Wetterwald、Atte Lansisalmi、Hannu Flinck、Bernard Aboba、Markku Tuohino、Wes George、Robert Sparks、S。Moonsesamy、Dave Crocker、Steve Crockerの各氏に特に感謝します。コメントを確認します。
Authors' Addresses
著者のアドレス
Hannes Tschofenig ARM Ltd. 6060 Hall in Tirol Austria
Hannes Tschofenig ARM Ltd. 6060 Hall in Tirolオーストリア
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Jari Arkko Jorvas 02420 Finland
Jari Arkko Jorvas 02420フィンランド
EMail: jari.arkko@piuha.net
Dave Thaler One Microsoft Way Redmond, WA 98052 United States
Dave Thaler One Microsoft Wayレドモンド、ワシントン州98052アメリカ合衆国
EMail: dthaler@microsoft.com
Danny McPherson 12061 Bluemont Way Reston, VA 20190 United States
Danny McPherson 12061 Bluemont Way Reston、VA 20190アメリカ
EMail: dmcpherson@verisign.com