[要約] RFC 9039は、デバイス識別子のための統一リソース名（URN）に関する規格です。この文書の目的は、ネットワーク上のデバイスを一意に識別するための標準的な方法を提供することにあります。利用場面としては、IoTデバイスの管理、ネットワーク機器の追跡、デバイス間の通信のセキュリティ強化などが挙げられます。
Internet Engineering Task Force (IETF) J. Arkko
Request for Comments: 9039 Ericsson
Category: Standards Track C. Jennings
ISSN: 2070-1721 Cisco
Z. Shelby
Edge Impulse
June 2021
Uniform Resource Names for Device Identifiers
デバイス識別子の統一リソース名
Abstract
概要
This document describes a new Uniform Resource Name (URN) namespace for hardware device identifiers. A general representation of device identity can be useful in many applications, such as in sensor data streams and storage or in equipment inventories. A URN-based representation can be passed along in applications that need the information.
このドキュメントでは、ハードウェアデバイス識別子の新しい統一リソース名（URN）ネームスペースについて説明します。デバイスIDの一般的な表現は、センサーデータストリームやストレージや機器のインベントリなどの多くのアプリケーションで役立ちます。URNベースの表現は、情報を必要とするアプリケーションに渡すことができます。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9039.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frfc9039で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Requirements Language
3. DEV URN Definition
3.1. Purpose
3.2. Syntax
3.2.1. Character Case and URN-Equivalence
3.3. Assignment
3.4. Security and Privacy
3.5. Interoperability
3.6. Resolution
3.7. Documentation
3.8. Additional Information
3.9. Revision Information
4. DEV URN Subtypes
4.1. MAC Addresses
4.2. 1-Wire Device Identifiers
4.3. Organization-Defined Identifiers
4.4. Organization Serial Numbers
4.5. Organization Product and Serial Numbers
4.6. Future Subtypes
5. Examples
6. Security Considerations
6.1. Privacy
6.2. Validity
7. IANA Considerations
8. References
8.1. Normative References
8.2. Informative References
Acknowledgments
Authors' Addresses
This document describes a new Uniform Resource Name (URN) [RFC8141] namespace for hardware device identifiers. A general representation of device identity can be useful in many applications, such as in sensor data streams and storage or in equipment inventories [RFC7252] [RFC8428] [CoRE-RD].
この文書では、ハードウェアデバイス識別子のための新しい統一リソース名（URN）[RFC8141]名前空間について説明します。デバイス識別情報の一般的な表現は、センサデータストリームや記憶装置や機器のインベントリなどの多くのアプリケーションで役立ちます[RFC7252] [RFC8428] [CORE-RD]。
A URN-based representation can be passed along in applications that need the information. It fits particularly well for protocols mechanisms that are designed to carry URNs [RFC7230] [RFC7540] [RFC3261] [RFC7252]. Finally, URNs can also be easily carried and stored in formats such as XML [W3C.REC-xml-19980210], JSON [RFC8259], or SenML [RFC8428]. Using URNs in these formats is often preferable as they are universally recognized and self-describing and therefore avoid the need to agree to interpret an octet string as a specific form of a Media Access Control (MAC) address, for instance. Passing URNs may consume additional bytes compared to, for instance, passing 4-byte binary IPv4 addresses, but the former offers some flexibility in return.
URNベースの表現は、情報を必要とするアプリケーションに渡すことができます。URNSを搭載するように設計されているプロトコルメカニズムに特に適しています[RFC7230] [RFC3261] [RFC7252]。最後に、URNはXML [W3C.REC-XML-19980210]、JSON [RFC8259]、またはSENML [RFC8428]などのフォーマットで簡単に携帯および保存することもできます。これらのフォーマットのURNを使用することは、それらが普遍的に認識され自己記述されているのでしばしば望ましく、したがってオクテット文字列を特定の形式のメディアアクセス制御（MAC）アドレスとして解釈することに同意する必要性を回避することが多い。URNSを渡すと、たとえば4バイトのバイナリIPv4アドレスを渡すと比較して追加のバイトを消費することがありますが、前者は引き換えにある程度の柔軟性を提供します。
This document defines identifier URN types for situations where no such convenient type already exists. For instance, [RFC6920] defines cryptographic identifiers, [RFC7254] defines International Mobile station Equipment Identity (IMEI) identifiers for use with 3GPP cellular systems, and [RFC8464] defines Mobile Equipment Identity (MEID) identifiers for use with 3GPP2 cellular systems. Those URN types should be employed when such identifiers are transported; this document does not redefine these identifiers in any way.
この文書は、そのような便利なタイプがすでに存在しない状況のための識別子URN型を定義しています。たとえば、[RFC6920]は暗号識別子を定義し、[RFC7254]は3GPPセルラーシステムで使用するための国際移動局機器ID（IMEI）識別子を定義し、[RFC8464]は3GPP2細胞系で使用するためのモバイル機器同一性（MEID）識別子を定義しています。そのような識別子が輸送されるときにそれらのURNタイプを採用する必要があります。この文書はこれらの識別子を決して再定義しません。
Universally Unique Identifier (UUID) URNs [RFC4122] are another alternative way to represent device identifiers and already support MAC addresses as one type of identifier. However, UUIDs can be inconvenient in environments where it is important that the identifiers be as simple as possible and where additional requirements on stable storage, real-time clocks, and identifier length can be prohibitive. Often, UUID-based identifiers are preferred for general purpose uses instead of the MAC-based device URNs defined in this document. The device URNs are recommended for constrained environments.
Universally Unique Identifier（UUID）URNS [RFC4122]は、デバイス識別子を表す別の代替方法であり、すでにMACアドレスを1つのタイプの識別子としてサポートしています。しかしながら、UUIDは、識別子ができるだけ単純であり、安定したストレージ、リアルタイムクロック、および識別子の長さの追加要件が重要であることが重要である環境では不便であり得る。多くの場合、このドキュメントで定義されているMACベースのデバイスURNの代わりに、UUIDベースの識別子が汎用使用に優先されます。デバイスURNは制約付き環境に推奨されます。
Future device identifier types can extend the device URN type defined in this document (see Section 7), or they can define their own URNs.
将来のデバイス識別子タイプは、このドキュメントで定義されているデバイスURNタイプを拡張できます（セクション7を参照）、または独自のURNを定義できます。
Note that long-term stable unique identifiers are problematic for privacy reasons and should be used with care as described in [RFC7721].
長期安定した固有識別子はプライバシー上の理由から問題があり、[RFC7721]に記載されているように慎重に使用する必要があります。
The rest of this document is organized as follows. Section 3 defines the "DEV" URN type, and Section 4 defines subtypes for IEEE MAC-48, EUI-48 and EUI-64 addresses, and 1-Wire device identifiers. Section 5 gives examples. Section 6 discusses the security and privacy considerations of the new URN type. Finally, Section 7 specifies the IANA registration for the new URN type and sets requirements for subtype allocations within this type.
この文書の残りの部分は次のように編成されています。セクション3は「DEV」URNタイプを定義し、セクション4はIEEE MAC-48、EUI-48およびEUI-64アドレス、および1-Wireデバイス識別子のサブタイプを定義します。セクション5は例を示します。セクション6は、新しいURN型のセキュリティとプライバシーの考慮事項について説明します。最後に、セクション7は新しいURN型のIANA登録を指定し、このタイプ内のサブタイプ割り当ての要件を設定します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
Namespace Identifier: "dev"
ネームスペース識別子： "dev"
Version: 1
バージョン：1
Date: 2020-06-24
日付：2020-06-24
Registrant: IETF and the CORE Working Group. Should the working group cease to exist, discussion should be directed to the Applications and Real-Time Area or general IETF discussion forums, or the IESG.
登録者：IETFとコアワーキンググループ。ワーキンググループが存在するのをやめるべきである場合、議論はアプリケーションとリアルタイムエリアまたは一般的なIETFディスカッションフォーラム、またはIESGに向けられます。
The DEV URNs identify devices with device-specific identifiers such as network card hardware addresses. DEV URNs are scoped to be globally applicable (see [RFC8141], Section 6.4.1) and, in general, enable systems to use these identifiers from multiple sources in an interoperable manner. Note that in some deployments, ensuring uniqueness requires care if manual or local assignment mechanisms are used, as discussed in Section 3.3.
DEV URNは、ネットワークカードのハードウェアアドレスなどの機器固有の識別子を持つデバイスを識別します。Dev URNはグローバルに適用されるようにスコープされます（[RFC8141]、6.4.1項を参照）、一般に、システムはこれらの識別子を相互運用可能な方法で複数のソースから使用できるようにすることができます。いくつかの展開では、セクション3.3で説明されているように、手動またはローカル割り当てメカニズムが使用されている場合に一意性が必要になることに注意してください。
Some typical DEV URN applications include equipment inventories and smart object systems.
いくつかの典型的なDEV URNアプリケーションは、機器の在庫とスマートオブジェクトシステムを含む。
DEV URNs can be used in various ways in applications, software systems, and network components, in tasks ranging from discovery (for instance, when discovering 1-Wire network devices or detecting MAC-addressable devices on a LAN) to intrusion detection systems and simple catalogues of system information.
Dev URNは、アプリケーション、ソフトウェアシステム、ネットワークコンポーネント、ディスカバリーからのタスク（たとえば、1-Wireネットワークデバイスを発見したり、LAN上のMACアドレス指定可能なデバイスの検出）や侵入検知システムとシンプルにさまざまな方法で使用できます。システム情報のカタログ
While it is possible to implement resolution systems for specific applications or network locations, DEV URNs are typically not used in a way that requires resolution beyond direct observation of the relevant identifier fields in local link communication. However, it is often useful to be able to pass device identifier information in generic URN fields in databases or protocol fields, which makes the use of URNs for this purpose convenient.
特定のアプリケーションまたはネットワークの場所に分解能システムを実装することは可能であるが、Dev URNは通常、ローカルリンク通信における関連識別子フィールドの直接観察を超えた解像度を必要とする方法では使用されない。ただし、この目的のためのURNの使用をデータベースまたはプロトコルフィールドの一般的なURNフィールドに渡すことができることがよくあります。
The DEV URN namespace complements existing namespaces such as those involving IMEI or UUID identifiers. DEV URNs are expected to be a part of the IETF-provided basic URN types, covering identifiers that have previously not been possible to use in URNs.
DEV URN名前空間は、IMEIまたはUUID識別子を含むものなどの既存のネームスペースを補完します。DEV URNは、URNSで使用できなかった識別子をカバーするIETFに提供された基本的なURN型の一部であると予想されます。
The identifier is expressed in ASCII characters and has a hierarchical structure as follows:
識別子はASCII文字で表され、次のように階層構造を持ちます。
devurn = "urn:dev:" body componentpart
body = macbody / owbody / orgbody / osbody / opsbody / otherbody
macbody = %s"mac:" hexstring
owbody = %s"ow:" hexstring
orgbody = %s"org:" posnumber "-" identifier *( ":" identifier )
osbody = %s"os:" posnumber "-" serial *( ":" identifier )
opsbody = %s"ops:" posnumber "-" product "-" serial
*( ":" identifier )
otherbody = subtype ":" identifier *( ":" identifier )
subtype = LALPHA *(DIGIT / LALPHA)
identifier = 1*devunreserved
identifiernodash = 1*devunreservednodash
product = identifiernodash
serial = identifier
componentpart = *( "_" identifier )
devunreservednodash = ALPHA / DIGIT / "."
devunreserved = devunreservednodash / "-"
hexstring = 1*(hexdigit hexdigit)
hexdigit = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
posnumber = NZDIGIT *DIGIT
ALPHA = %x41-5A / %x61-7A
LALPHA = %x41-5A
NZDIGIT = %x31-39
DIGIT = %x30-39
The above syntax is represented in Augmented Backus-Naur Form (ABNF) as defined in [RFC5234] and [RFC7405]. The syntax also copies the DIGIT and ALPHA rules originally defined in [RFC5234], exactly as defined there.
上記の構文は、[RFC5234]および[RFC7405]で定義されているように、増強された背景 - Naur形（ABNF）に表される。構文は、最初に定義されたとおりに[RFC5234]で定義されている数字とアルファの規則もコピーします。
The device identifier namespace includes five subtypes (see Section 4), and more may be defined in the future as specified in Section 7.
デバイス識別子ネームスペースには5つのサブタイプが含まれています（セクション4を参照）、セクション7で指定されているように、将来的に定義されてもよい。
The optional underscore-separated components at the end of the DEV URN depict individual aspects of a device. The specific strings and their semantics are up to the designers of the device but could be used to refer to specific interfaces or functions within the device.
DEV URNの最後のオプションのアンダースコア区切り成分は、装置の個々の側面を描写する。特定の文字列とそれらの意味論はデバイスの設計者次第ですが、デバイス内の特定のインターフェイスまたは機能を指すために使用できます。
With the exception of the MAC address and 1-Wire DEV URNs, each DEV URN may also contain optional colon-separated identifiers. These are provided for extensibility.
MACアドレスと1線のDEV URNを除いて、各DEV URNにはオプションのコロン区切り識別子も含めることができます。これらは拡張性のために提供されています。
There are no special character encoding rules or considerations for conforming with the URN syntax beyond those applicable for URNs in general [RFC8141] or the context where these URNs are carried (e.g., inside JSON [RFC8259] or SenML [RFC8428]). Due to the SenML rules in [RFC8428], Section 4.5.1, it is not desirable to use percent-encoding in DEV URNs, and the subtypes defined in this specification do not really benefit from percent-encoding. However, this specification does not deviate from the general syntax of URNs or their processing and normalization rules as specified in [RFC3986] and [RFC8141].
一般的な[RFC8141]のURNに適用可能なものやこれらのURNが運ばれるコンテキストを超えて、（例えば、JSON [RFC8259]またはSENML [RFC8259]の内部）を超えてURN構文に準拠するための特別な文字エンコード規則はありません。[RFC8428]、セクション4.5.1のSENML規則により、DEV URNSでパーセントエンコーディングを使用することは望ましくなく、この仕様で定義されているサブタイプはパーセントエンコーディングから実に有益ではありません。ただし、この仕様は、[RFC3986]と[RFC8141]で指定されているURNの一般的な構文やその処理と正規化規則から逸脱しません。
DEV URNs do not use r-, q-, or f-components as defined in [RFC8141].
DEV URNS [RFC8141]で定義されているR、Q、またはFコンポーネントを使用しません。
Specific subtypes of DEV URNs may be validated through mechanisms discussed in Section 4.
DEV URNの特定のサブタイプは、セクション4で説明したメカニズムを通じて検証されてもよい。
The string representation of the device identifier URN is fully compatible with the URN syntax.
デバイス識別子URNの文字列表現は、URN構文と完全に互換性があります。
The DEV URN syntax allows both uppercase and lowercase characters. The URN-equivalence of the DEV URNs is defined per [RFC8141], Section 3.1, i.e., two URNs are URN-equivalent if their assigned-name portions are octet-by-octet equal after applying case normalization to the URI scheme ("urn") and namespace identifier ("dev"). The rest of the DEV URN is compared in a case-sensitive manner. It should be noted that URN-equivalence matching merely quickly shows that two URNs are definitely the same for the purposes of caching and other similar uses. Two DEV URNs may still refer to the same entity and may not be found to be URN-equivalent according to the [RFC8141] definition. For instance, in ABNF, strings are case insensitive (see [RFC5234], Section 2.3), and a MAC address could be represented either with uppercase or lowercase hexadecimal digits.
DEV URN構文では、大文字と小文字の両方を許可します。DEV URNのURN-INSIQUMENは、[RFC8141]、セクション3.1、つまり2つのURNは、URIスキームにケース正規化を適用した後に割り当てられた名前部分がオクテットバイオクテットである場合には、2つのURNがurn-italitです（ "URN"）および名前空間識別子（" dev "）。残りのDEV URNは、大文字と小文字を区別して比較されます。URN - 等価マッチングは、2つのURNがキャッシングやその他の同様の用途の目的のために間違いなく同じであることをすばやく示しているだけであることに注意すべきです。2つのDEV URNは依然として同じエンティティを参照することができ、[RFC8141]定義によると、URNと同等であることがわからない場合があります。たとえば、ABNFでは、文字列は大文字と小文字が区別されません（[RFC5234]、セクション2.3を参照）、MACアドレスは大文字または小文字の16進数で表すことができます。
Character case is not otherwise significant for the DEV URN subtypes defined in this document. However, future subtypes might include identifiers that use encodings such as base64, which encodes strings in a larger variety of characters and might even encode binary data.
このドキュメントで定義されているDev URNサブタイプには、その他の点では文字ケースが重要ではありません。ただし、将来のサブタイプには、Base64などのエンコーディングを使用する識別子が含まれている場合があります。これは、文字列をより多様な文字でエンコードし、バイナリデータをエンコードする可能性があります。
To facilitate equivalence checks, it is RECOMMENDED that implementations always use lowercase letters where they have a choice in case, unless there is a reason otherwise. (Such a reason might be, for instance, the use of a subtype that requires the use of both uppercase and lowercase letters.)
等価チェックを容易にするために、実装は常に理由がない限り、常に選択肢がある場合は小文字を使用することをお勧めします。（たとえば、大文字と小文字の両方を使用する必要があるサブタイプの使用などです。）
The process for identifier assignment is dependent on the used subtype and is documented in the specific subsection under Section 4.
識別子割り当てのプロセスは、使用されたサブタイプによって異なり、セクション4の特定のサブセクションに記載されています。
Device identifiers are generally expected to identify a unique device, barring the accidental issue of multiple devices with the same identifiers. In many cases, device identifiers can also be changed by users or are sometimes assigned in an algorithmic or local fashion. Any potential conflicts arising from such assignments are not something that the DEV URNs as such manage; they simply are there to refer to a particular identifier. And, of course, a single device may (and often does) have multiple identifiers, e.g., identifiers associated with different link technologies it supports.
デバイス識別子は一般に、同じ識別子を持つ複数のデバイスの偶発的な問題を識別する独自のデバイスを識別することが期待されています。多くの場合、デバイス識別子はユーザーによって変更することも、アルゴリズムまたはローカルの方法で割り当てられます。そのような課題から生じる潜在的な矛盾は、そのような管理としてDEV URNが属しているものではありません。それらは単に特定の識別子を参照するためのものです。そして、もちろん、単一の装置が（そして多くの場合、しばしばする）が複数の識別子、例えばそれがサポートするさまざまなリンク技術に関連する識別子を有することができる。
The DEV URN type SHOULD only be used for hardware-based identifiers that are expected to be persistent (with some limits, as discussed above).
DEV URNタイプは、永続的であると予想されるハードウェアベースの識別子にのみ使用されます（上記のように、いくつかの制限付き）。
As discussed in Section 6, care must be taken in the use of device-identifier-based identifiers due to their nature as long-term identifiers that are not normally changeable. Leakage of these identifiers outside systems where their use is justified should be controlled.
セクション6で説明したように、通常は変更可能ではない長期識別子としてのそれらの性質のために、デバイス識別子ベースの識別子の使用に注意を払わなければならない。それらの使用が正当化されるべきシステム外のこれらの識別子の漏洩を制御する必要があります。
There are no specific interoperability concerns.
特定の相互運用性の懸念はありません。
The device identifiers are not expected to be globally resolvable. No identifier resolution system is expected. Systems may perform local matching of identifiers to previously seen identifiers or configured information, however.
デバイス識別子は、グローバルに解決可能であるとは予想されません。識別子の解像度システムは予想されません。しかしながら、システムは、識別子のローカルマッチングまたは前述の識別子または構成された情報を実行することができる。
See RFC 9039.
RFC 9039を参照してください。
See Section 1 for a discussion of related namespaces.
関連ネームスペースの説明についてはセクション1を参照してください。
This is the first version of this registration.
これがこの登録の最初のバージョンです。
DEV URNs of the "mac" subtype are based on the EUI-64 identifier [IEEE.EUI64] derived from a device with a built-in 64-bit EUI-64. The EUI-64 is formed from 24 or 36 bits of organization identifier followed by 40 or 28 bits of device-specific extension identifier assigned by that organization.
「MAC」サブタイプのDEV URNは、64ビットEUI-64を内蔵したデバイスから派生したEUI-64識別子[IEEE.EUI64]に基づいています。EUI-64は、24または36ビットの組織識別子から形成され、続いてその組織によって割り当てられた40または28ビットのデバイス固有の拡張識別子が続きます。
In the DEV URN "mac" subtype, the hexstring is simply the full EUI-64 identifier represented as a hexadecimal string. It is always exactly 16 characters long.
DEV URNの「MAC」サブタイプでは、ヘクスシュリングは単に16進数文字列として表される完全なEUI-64識別子です。それは常に16文字の長さです。
MAC-48 and EUI-48 identifiers are also supported by the same DEV URN subtype. To convert a MAC-48 address to an EUI-64 identifier, the Organizationally Unique Identifier (OUI) of the MAC-48 address (the first three octets) becomes the organization identifier of the EUI-64 (the first three octets). The fourth and fifth octets of the EUI are set to the fixed value 0xffff (hexadecimal). The last three octets of the MAC-48 address become the last three octets of the EUI-64. The same process is used to convert an EUI-48 identifier, but the fixed value 0xfffe is used instead.
MAC-48およびEUI-48識別子も同じDEV URNサブタイプによってサポートされています。MAC-48アドレスをEUI-64識別子に変換するには、MAC-48アドレス（最初の3オクテット）の組織的に一意の識別子（OUI）がEUI-64（最初の3オクテット）の組織識別子になります。EUIの4番目と5オクテットは、固定値0xFFFF（16進数）に設定されています。MAC-48アドレスの最後の3オクテットは、EUI-64の最後の3オクテットになります。同じプロセスがEUI-48識別子を変換するために使用されますが、代わりに固定値0xFFFEが使用されます。
Identifier assignment for all of these identifiers rests within the IEEE Registration Authority.
これらすべての識別子の識別子割り当ては、IEEE登録局内で依存します。
Note that where randomized MAC addresses are used, the resulting DEV URNs cannot be expected to have uniqueness, as discussed in Section 3.3.
ランダム化されたMACアドレスが使用される場合、セクション3.3で説明したように、結果のDEV URNは一意性を持つことが期待できないことに注意してください。
The 1-Wire system is a device communications bus system designed by Dallas Semiconductor Corporation. (1-Wire is a registered trademark.) 1-Wire devices are identified by a 64-bit identifier that consists of an 8-bit family code, a 48-bit identifier unique within a family, and an 8-bit Cyclic Redundancy Check (CRC) code [OW].
1線式システムは、Dallas Semiconductor Corporationによって設計されたデバイス通信バスシステムです。（1-Wireは登録商標です。）1-Wireデバイスは、8ビットのファミリコード、ファミリ内で一意の48ビット識別子、および8ビットの巡回冗長検査で構成される64ビット識別子によって識別されます。（CRC）[OW]。
In DEV URNs with the "ow" subtype, the hexstring is a representation of the full 64-bit identifier as a hexadecimal string. It is always exactly 16 characters long. Note that the last two characters represent the 8-bit CRC code. Implementations MAY check the validity of this code.
「OW」サブタイプを持つDEV URNSでは、HexStringは16進数文字列としてのフル64ビット識別子の表現です。それは常に16文字の長さです。最後の2文字は8ビットCRCコードを表します。実装はこのコードの妥当性を確認できます。
Family code and identifier assignment for all 1-Wire devices rests with the manufacturers.
すべての1線式装置の家族コードと識別子の割り当ては製造業者とともに休みます。
Device identifiers that have only a meaning within an organization can also be used to represent vendor-specific or experimental identifiers or identifiers designed for use within the context of an organization.
組織内の意味を持つデバイス識別子は、組織のコンテキスト内で使用するように設計されたベンダー固有または実験的識別子または識別子を表すためにも使用できます。
Organizations are identified by their Private Enterprise Number (PEN) [RFC2578]. These numbers can be obtained from IANA. Current PEN assignments can be viewed at <https://www.iana.org/assignments/ enterprise-numbers/>, and new assignments are requested at <https://pen.iana.org/pen/PenApplication.page>.
組織は、プライベートエンタープライズ番号（PEN）[RFC2578]によって識別されます。これらの数字はIANAから入手できます。現在のペン割り当ては<https://www.iana.org/ashignments/ envertand-numbers />で表示でき、新しい割り当ては<https://pen.iana.org/pen/penapplication.page>で要求されます。
Note that when included in an "org" DEV URN, the number cannot be zero or have leading zeroes, as the ABNF requires the number to start with a non-zero digit.
「ORG」DEV URNに含まれている場合、ABNFはゼロ以外の数字で始まる数を必要とするため、数値はゼロまたは先行ゼロを持つことはできません。
The "os" subtype specifies an organization and serial number. Organizations are identified by their PEN. As with the organization-defined identifiers (Section 4.3), PEN number assignments are maintained by IANA, and assignments for new organizations can be made easily.
「OS」サブタイプは、組織とシリアル番号を指定します。組織はペンによって識別されます。組織定義識別子（セクション4.3）と同様に、PEN番号の割り当てはIANAによって維持され、新しい組織の割り当てを簡単に行うことができます。
| Historical note: The "os" subtype was originally defined in the
| Open Mobile Alliance "Lightweight Machine to Machine" standard
| [LwM2M] but has been incorporated here to collect all syntaxes
| associated with DEV URNs in one place. At the same time, the
| syntax of this subtype was changed to avoid the possibility of
| characters that are not allowed in the SenML Name field (see
| [RFC8428], Section 4.5.1).
Organization serial number DEV URNs consist of the PEN number and the serial number. As with other DEV URNs, for carrying additional information and extensibility, optional colon-separated identifiers and underscore-separated components may also be included. The serial numbers themselves are defined by the organization, and this specification does not specify how they are allocated.
組織シリアル番号DEV URNは、ペン番号とシリアル番号で構成されています。追加情報および拡張性を担持するための他のDev URNと同様に、オプションのコロン区切り識別子およびアンダースコア区切り成分も含まれ得る。シリアル番号自体が組織によって定義されており、この仕様はそれらがどのように割り当てられているかを指定しません。
Organizations are also encouraged to select serial number formats that avoid the possibility of ambiguity in the form of leading zeroes or otherwise.
組織はまた、先頭のゼロの形であいまいさの可能性を回避するシリアル番号のフォーマットを選択することが奨励されています。
The DEV URN "ops" subtype was originally defined in the LwM2M standard but has been incorporated here to collect all syntaxes associated with DEV URNs in one place. The "ops" subtype specifies an organization, product class, and a serial number. Organizations are identified by their PEN. Again, as with the organization-defined identifiers (Section 4.3), PEN number assignments are maintained by IANA.
DEV URNの「OPS」サブタイプはもともとLWM2M標準で定義されていましたが、ここにはDev URNに関連付けられているすべての構文を1か所に収集しました。"ops"サブタイプは、組織、製品クラス、およびシリアル番号を指定します。組織はペンによって識別されます。繰り返しますが、組織定義識別子（セクション4.3）と同様に、ペン番号の割り当てはIANAによって維持されます。
| Historical note: As with the "os" subtype, the "ops" subtype
| was originally defined in the Open Mobile Alliance "Lightweight
| Machine to Machine" standard [LwM2M].
Organization product and serial number DEV URNs consist of the PEN number, product class, and the serial number. As with other DEV URNs, for carrying additional information and extensibility, optional colon-separated identifiers and underscore-separated components may also be included. Both the product class and serial numbers themselves are defined by the organization, and this specification does not specify how they are allocated.
組織製品およびシリアル番号DEV URNは、ペン番号、製品クラス、およびシリアル番号で構成されています。追加情報および拡張性を担持するための他のDev URNと同様に、オプションのコロン区切り識別子およびアンダースコア区切り成分も含まれ得る。製品クラスとシリアル番号自体の両方が組織によって定義されており、この仕様はそれらがどのように割り当てられているかを指定しません。
Organizations are also encouraged to select product and serial number formats that avoid possibility for ambiguity.
団体は、あいまいさの可能性を避ける製品とシリアル番号のフォーマットを選択することも奨励されています。
Additional subtypes may be defined in future specifications. See Section 7.
追加のサブタイプは将来の仕様で定義されている可能性があります。7を参照してください。
The DEV URN "example" subtype is reserved for use in examples. It has no specific requirements beyond those expressed by the ABNF in Section 3.2.
DEV URN「例」サブタイプは、例で使用するために予約されています。それはセクション3.2のABNFによって表されるものを超えて特定の要件を持っていません。
The following provides some examples of DEV URNs:
以下はDEV URNの例をいくつか示しています。
+=========================================+=========================+
| URN | Description |
+=========================================+=========================+
| urn:dev:mac:0024beffff804ff1 | The MAC-48 address of |
| | 0024be804ff1, |
| | converted to EUI-64 |
| | format |
+-----------------------------------------+-------------------------+
| urn:dev:mac:0024befffe804ff1 | The EUI-48 address of |
| | 0024be804ff1, |
| | converted to EUI-64 |
| | format |
+-----------------------------------------+-------------------------+
| urn:dev:mac:acde48234567019f | The EUI-64 address of |
| | acde48234567019f |
+-----------------------------------------+-------------------------+
| urn:dev:ow:10e2073a01080063 | A 1-Wire temperature |
| | sensor |
+-----------------------------------------+-------------------------+
| urn:dev:ow:264437f5000000ed_humidity | The humidity part of |
| | a multi-sensor device |
+-----------------------------------------+-------------------------+
| urn:dev:ow:264437f5000000ed_temperature | The temperature part |
| | of a multi-sensor |
| | device |
+-----------------------------------------+-------------------------+
| urn:dev:org:32473-foo | An organization- |
| | specific URN in the |
| | example organization |
| | 32473 in [RFC5612] |
+-----------------------------------------+-------------------------+
| urn:dev:os:32473-123456 | Device 123456 in the |
| | example organization |
| | in [RFC5612] |
+-----------------------------------------+-------------------------+
| urn:dev:os:32473-12-34-56 | A serial number with |
| | dashes in it |
+-----------------------------------------+-------------------------+
| urn:dev:ops:32473-Refrigerator-5002 | Refrigerator serial |
| | number 5002 in the |
| | example organization |
| | in [RFC5612] |
+-----------------------------------------+-------------------------+
| urn:dev:example:new-1-2-3_comp | An example of |
| | something that is not |
| | defined today, and is |
| | not one of the mac, |
| | ow, os, or ops |
| | subtypes |
+-----------------------------------------+-------------------------+
Table 1
表1
The DEV URNs themselves can then appear in various contexts. A simple example of this is the use of DEV URNs in SenML data. This example from [RFC8428] shows a measurement from a 1-Wire temperature gauge encoded in the JSON syntax:
その後、Dev Urns自体はさまざまなコンテキストに表示されます。これの簡単な例は、SENMLデータ内のDEV URNの使用です。[RFC8428]からのこの例は、JSON構文で符号化された1線式温度ゲージからの測定値を示しています。
[
{"n":"urn:dev:ow:10e2073a01080063","u":"Cel","v":23.1}
]
On most devices, the user can display device identifiers. Depending on circumstances, device identifiers may or may not be modified or tampered with by the user. An implementation of the DEV URN MUST preserve such limitations and behaviors associated with the device identifiers. In particular, a device identifier that is intended to be immutable should not become mutable as a part of implementing the DEV URN type. More generally, nothing in this document should be construed to override what the relevant device specifications have already said about the identifiers.
ほとんどのデバイスでは、ユーザーはデバイス識別子を表示できます。状況に応じて、デバイス識別子はユーザーが変更または改ざんできない場合があります。DEV URNの実装は、デバイス識別子に関連するそのような制限および動作を保持しなければならない。特に、不変であることを意図した装置識別子は、DEV URN型を実施する部分として変動することはできない。より一般的には、この文書内では、関連するデバイス仕様が識別子についてすでに言っていることを超えると解釈されるべきではありません。
Other devices in the same network may or may not be able to identify the device. For instance, on an Ethernet network, the MAC address of a device is visible to all other devices.
同じネットワーク内の他のデバイスは、デバイスを識別できない場合があります。たとえば、イーサネットネットワークでは、デバイスのMACアドレスは他のすべてのデバイスに表示されます。
DEV URNs often represent long-term stable unique identifiers for devices. Such identifiers may have privacy and security implications because they may enable correlating information about a specific device over a long period of time, location tracking, and device-specific vulnerability exploitation [RFC7721]. Also, in some systems, there is no easy way to change the identifier. Therefore, these identifiers need to be used with care, and special care should be taken to avoid leaking identifiers outside of the system that is intended to use them.
Dev Urnsはしばしばデバイスの長期安定した固有の識別子を表します。そのような識別子は、長期間、位置追跡、およびデバイス固有の脆弱性活動[RFC7721]にわたって特定の装置に関する情報を相関させることを可能にし得るので、プライバシーおよびセキュリティの意味を有することができる。また、システムによっては、識別子を変更する簡単な方法はありません。したがって、これらの識別子を慎重に使用する必要があり、それらを使用することを意図しているシステムの外部で識別子を漏らさないように特別な注意を払う必要があります。
Information about identifiers may have significant effects in some applications. For instance, in many sensor systems, the identifier information is used for deciding how to use the data carried in a measurement report. In some other systems, identifiers may be used in policy decisions.
識別子に関する情報は、一部のアプリケーションでは大きな影響を与える可能性があります。例えば、多くのセンサシステムでは、識別子情報は、測定報告で運ばれるデータの使用方法を決定するために使用される。他のいくつかのシステムでは、識別子は政策決定において使用され得る。
It is important that systems be designed to take into account the possibility of devices reporting incorrect identifiers (either accidentally or maliciously) and the manipulation of identifiers in communications by illegitimate entities. Integrity protection of communications or data objects, the use of trusted devices, and various management practices can help address these issues.
システムは、誤った識別子を誤って報告する可能性（誤ってまたは悪意がある）および違法なエンティティによる通信における識別子の操作を考慮に入れるようにすることが重要です。通信またはデータオブジェクトの完全性保護、信頼できるデバイスの使用、およびさまざまな管理慣行は、これらの問題に対処するのに役立ちます。
Similar to the advice in [RFC4122], Section 6: Do not assume that DEV URNs are hard to guess.
[RFC4122]のアドバイスと同様に、セクション6：Dev Urnsが推測が難しいと仮定しないでください。
Per this document, IANA has registered a new URN namespace for "dev", as described in Section 3.
このドキュメントごとに、IANAはセクション3で説明されているように、 "dev"の新しいURNネームスペースを登録しました。
IANA has created a "DEV URN Subtypes" registry under "Device Identification". The initial values in this registry are as follows:
IANAは「デバイスの識別」の下に「DEV URNサブタイプ」レジストリを作成しました。このレジストリの初期値は次のとおりです。
+=========+===========================+=======================+
| Subtype | Description | Reference |
+=========+===========================+=======================+
| mac | MAC Addresses | RFC 9039, Section 4.1 |
+---------+---------------------------+-----------------------+
| ow | 1-Wire Device Identifiers | RFC 9039, Section 4.2 |
+---------+---------------------------+-----------------------+
| org | Organization-Defined | RFC 9039, Section 4.3 |
| | Identifiers | |
+---------+---------------------------+-----------------------+
| os | Organization Serial | RFC 9039, Section 4.4 |
| | Numbers | |
+---------+---------------------------+-----------------------+
| ops | Organization Product and | RFC 9039, Section 4.5 |
| | Serial Numbers | |
+---------+---------------------------+-----------------------+
| example | Reserved for examples | RFC 9039, Section 4.6 |
+---------+---------------------------+-----------------------+
Table 2
表2.
Additional subtypes for DEV URNs can be defined through Specification Required or IESG Approval [RFC8126]. These allocations are appropriate when there is a new namespace of some type of device identifier that is defined in a stable fashion and has a publicly available specification.
DEV URNの追加のサブタイプは、必要な仕様またはIESG承認[RFC8126]を通じて定義できます。これらの割り当ては、安定した方法で定義されており、公的に利用可能な仕様を持つ、ある種のデバイス識別子の新しいネームスペースがある場合に適しています。
Note that the organization (Section 4.3) device identifiers can also be used in some cases, at least as a temporary measure. It is preferable, however, that long-term usage of a broadly employed device identifier be registered with IETF rather than used through the organization device identifier type.
少なくとも一時的な測定値として、組織（セクション4.3）の装置識別子を使用することもできます。しかしながら、幅広く採用されている装置識別子の長期使用は、組織デバイス識別子タイプを介して使用されるのではなくIETFに登録されることが好ましい。
[IEEE.EUI64] IEEE, "Guidelines for Use of Extended Unique Identifier (EUI), Organizationally Unique Identifier (OUI), and Company ID (CID)", August 2017, <https://standards.ieee.org/content/dam/ieee-standards/standards/web/documents/tutorials/eui.pdf>.
[IEEE.EUI64] IEEE、「拡張固有の識別子（EUI）、組織的に固有の識別子（OUI）、および会社ID（CID）、および会社ID（CID） "、<https://standards.ieee.org/content/DAM / IEEE規格/標準/ Web / Documents / Tutorials / EUI.PDF>。
[OW] Maxim, "Guide to 1-Wire Communication", June 2008, <https://www.maximintegrated.com/en/design/technical-documents/tutorials/1/1796.html>.
[OW]マキシム「1-Wire Communicationのガイド」、2008年6月、<https：//www.maximintegrated.com/en/design/technical-documents/tutorials/1/1796.html>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, DOI 10.17487/RFC2578, April 1999, <https://www.rfc-editor.org/info/rfc2578>.
[RFC2578] McCloghrie、K。、ED。、Perkins、D.、Ed。、およびJ.Schoenwaelder、ED。、「管理情報バージョン2（SMIV2）の構造（STD 58）、RFC 2578、DOI 10.17487 / RFC2578、1999年4月、<https：//www.rfc-editor.org/info/rfc2578>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Field、R.、およびL.Masinter、「Uniform Resource Identifier（URI）：汎用構文」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<https：//www.rfc-editor.org/info/rfc3986>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234] Crocker、D.、ED。2008年1月、<https://www.rfc-editor.org/info/rfc-editor.org/info/rfc- editor.org/info/rfc523,2008、<https://www.rfc-editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc5234>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]綿、M.、Leiba、B.およびT.Narten、「RFCSのIANAに関する考察のためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<HTTPS：// WWW.rfc-editor.org / info / rfc8126>。
[RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, <https://www.rfc-editor.org/info/rfc8141>.
[RFC8141] Saint-Andre、P.およびJ.Klensin、「ユニフォームリソース名（URNS）」、RFC 8141、DOI 10.17487 / RFC8141、2017年4月、<https：//www.rfc-editor.org/info/rfc8141>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[CoRE-RD] Amsüss, C., Ed., Shelby, Z., Koster, M., Bormann, C., and P. van der Stok, "CoRE Resource Directory", Work in Progress, Internet-Draft, draft-ietf-core-resource-directory-28, 7 March 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-core-resource-directory-28>.
[CORE-RD] Amsss、C.、ED。、Shelby、Z.、Koster、M.、Bormann、C.、およびP。Van Der Stok、「コアリソースディレクトリ」、進行中、インターネットドラフト、ドラフト-ietf-core-resource-directory-28,29月7日、<https：//datatracker.ietf.org/doc/html/draft-ietf-core-resource-Directory-28>。
[LwM2M] Alliance, O. M., "OMA Lightweight Machine to Machine Requirements", OMA Standard Candidate Version 1.2, January 2019, <https://www.openmobilealliance.org/release/ LightweightM2M/V1_2-20190124-C/OMA-RD-LightweightM2M-V1_2-20190124-C.pdf>.
[LWM2M] Alliance、OM、「マシン要件 - マシン要件」、2019年1月、<https://www.openmobilealliance.org/release/ LightweightM2M / V1_2-20190124-C / OMA-RD-LightWeightM2M-V1_2-20190124-C.PDF>。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M.、E. Schooler、「SIP：セッション開始プロトコル」、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<https://www.rfc-editor.org/info/rfc3261>。
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, <https://www.rfc-editor.org/info/rfc4122>.
[RFC4122]リーチ、P.、Mealling、M.、およびR.Salz、「普遍的にユニークな識別子（UUID）URN名前空間」、RFC 4122、DOI 10.17487 / RFC4122、2005年7月、<https：//www.rfc-editor.org/info/rfc4122>。
[RFC5612] Eronen, P. and D. Harrington, "Enterprise Number for Documentation Use", RFC 5612, DOI 10.17487/RFC5612, August 2009, <https://www.rfc-editor.org/info/rfc5612>.
[RFC5612] ERONEN、P.およびD.Harrington、2009年8月、<https：//www.rfc-editor.org/info/rfc5612>。
[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A., and P. Hallam-Baker, "Naming Things with Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, <https://www.rfc-editor.org/info/rfc6920>.
[RFC6920] Farrell、S.、Kutscher、D.、Dannewitz、C.、Ohlman、B.、Keranen、A.、およびP.Hallam-Baker、「ハッシュ付きのもの」、RFC 6920、DOI 10.17487 / RFC6920、2013年4月、<https：//www.rfc-editor.org/info/rfc6920>。
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230]フィールド、R.、ED。J.Reschke、ED。、「Hypertext Transfer Protocol（HTTP / 1.1）：メッセージ構文とルーティング」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<https：//www.rfc-editor.org/info/RFC7230>。
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>.
[RFC7252] Shelby、Z.、Hartke、K.、C. Bormann、「制約付きアプリケーションプロトコル（CoAP）」、RFC 7252、DOI 10.17487 / RFC7252、2014年6月、<https：//www.rfc-編集者。ORG / INFO / RFC7252>。
[RFC7254] Montemurro, M., Ed., Allen, A., McDonald, D., and P. Gosden, "A Uniform Resource Name Namespace for the Global System for Mobile Communications Association (GSMA) and the International Mobile station Equipment Identity (IMEI)", RFC 7254, DOI 10.17487/RFC7254, May 2014, <https://www.rfc-editor.org/info/rfc7254>.
[RFC7254] Montemurro、M.、ED。、Allen、A.、McDonald、D.、およびP. Gosden、「モバイル通信協会のためのグローバルシステム（GSMA）および国際移動局機器のアイデンティティ（IMEI） "、RFC 7254、DOI 10.17487 / RFC7254、2014年5月、<https://www.rfc-editor.org/info/rfc7254>。
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI 10.17487/RFC7405, December 2014, <https://www.rfc-editor.org/info/rfc7405>.
[RFC7405] KYZIVAT、P.、「ABNFの大文字と小文字の区別文字列サポート」、RFC 7405、DOI 10.17487 / RFC7405、2014年12月、<https：//www.rfc-editor.org/info/rfc7405>。
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, <https://www.rfc-editor.org/info/rfc7540>.
[RFC7540] Belshe、M.、Peon、R.およびM.Thomson、Ed。、「Hypertext Transfer Protocol Version 2（HTTP / 2）」、RFC 7540、DOI 10.17487 / RFC7540、2015年5月、<https：//www.rfc-editor.org/info/rfc7540>。
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016, <https://www.rfc-editor.org/info/rfc7721>.
[RFC7721] Cooper、A.、Gont、F.、およびD.Thaler、「IPv6アドレス生成メカニズムのためのセキュリティとプライバシーに関する考察」、RFC 7721、DOI 10.17487 / RFC7721、2016年3月、<https：///www.rfc-Editor.org/info/rfc7721>。
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8259] Bray、T.、ED。、「JavaScriptオブジェクト表記（JSON）データ交換フォーマット」、STD 90、RFC 8259、DOI 10.17487 / RFC8259、2017年12月、<https：//www.rfc-editor.org/ info / rfc8259>。
[RFC8428] Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. Bormann, "Sensor Measurement Lists (SenML)", RFC 8428, DOI 10.17487/RFC8428, August 2018, <https://www.rfc-editor.org/info/rfc8428>.
[RFC8428]ジェニングニング、C、Shelby、Z.、Arkko、J.、Keranen、A.、C. Bormann、C. Bormann、「センサ測定リスト（SenML）」、RFC 8428、DOI 10.17487 / RFC8428、2018年8月、<HTTPS///www.rfc-editor.org/info/rfc8428>。
[RFC8464] Atarius, R., "A URN Namespace for Device Identity and Mobile Equipment Identity (MEID)", RFC 8464, DOI 10.17487/RFC8464, September 2018, <https://www.rfc-editor.org/info/rfc8464>.
[RFC8464] ATARIUS、R.、「デバイスIDとモバイル機器IDのURN名前空間（MEID）」、RFC 8464、DOI 10.17487 / RFC8464、2018年9月、<https：//www.rfc-editor.org/info/RFC8464>。
[W3C.REC-xml-19980210] Sperberg-McQueen, C., Bray, T., and J. Paoli, "Extensible Markup Language (XML) 1.0", W3C Recommendation, February 1998, <http://www.w3.org/TR/1998/REC-xml-19980210>.
[W3C.REC-XML-19980210] Sperberg-McQueen、C、Breay、T.、J.Paoli、「Extensible Markup Language（XML）1.0」、W3C勧告、1998年2月、<http：//www.w3.ORG / TR / 1998 / REC-XML-19980210>。
Acknowledgments
謝辞
The authors would like to thank Ari Keränen, Stephen Farrell, Christer Holmberg, Peter Saint-Andre, Wouter Cloetens, Jaime Jimenez, Joseph Knapp, Padmakumar Subramani, Mert Ocak, Hannes Tschofenig, Jim Schaad, Thomas Fossati, Carsten Bormann, Marco Tiloca, Barry Leiba, Amanda Baber, Juha Hakala, Dale Worley, Warren Kumari, Benjamin Kaduk, Brian Weis, John Klensin, Dave Thaler, Russ Housley, Dan Romascanu, Éric Vyncke, Roman Danyliw, and Ahmad Muhanna for their feedback and interesting discussions in this problem space. We would also like to note prior documents that focused on specific device identifiers, such as [RFC7254] and [RFC8464].
著者らは、AriKeränen、Stephen Farrell、Christer Holmberg、Peter Saint-Andre、Peter Cloetens、Joseph Knapp、Joseph Knapp、Jime Knapp、Merthaax、Thomas Fossati、Carsten Bormann、Marco Tiloca、Merco Marka、Barry Leiba、Amanda Baber、Juha Hakala、Dale Warley、Warren Kumari、Benjamin Kaduk、Brian Weis、John Klensin、Dave Thaler、Russ Ousle、Dan Romascanu、エリオンビンケ、ローマDanyliw、およびAhmad Muhannaこのフィードバックと興味深い議論問題スペース[RFC7254]や[RFC8464]など、特定のデバイス識別子に焦点を当てた以前の文書にも注意します。
Authors' Addresses
著者の住所
Jari Arkko Ericsson FI-02420 Jorvas Finland
Jari Arkko Ericsson FI-02420 Jorvas Finland.
Email: jari.arkko@piuha.net
Cullen Jennings Cisco 170 West Tasman Drive San Jose, CA 95134 United States of America
Cullen Jennings Cisco 170 West Tasman Drive San Jose、CA 95134アメリカ
Phone: +1 408 421-9990
Email: fluffy@iii.ca
Zach Shelby Edge Impulse 3031 Tisch Way San Jose, CA 95128 United States of America
Zach Shelby Edge Impulse 3031 Tisch Way San Jose、CA 95128アメリカ
Email: zach@edgeimpulse.com