diff --git a/data/9000/rfc9563-trans.json b/data/9000/rfc9563-trans.json new file mode 100644 index 000000000..1010bd654 --- /dev/null +++ b/data/9000/rfc9563-trans.json @@ -0,0 +1,449 @@ +{ + "title": { + "text": "RFC 9563 - SM2 Digital Signature Algorithm for DNSSEC", + "ja": "RFC 9563 - DNSSECのSM2デジタル署名アルゴリズム" + }, + "number": 9563, + "created_at": "2024-12-07 17:32:38.891297+09:00", + "updated_by": "", + "contents": [ + { + "indent": 0, + "text": "Independent Submission C. Zhang\nRequest for Comments: 9563 Y. Liu\nCategory: Informational F. Leng\nISSN: 2070-1721 Q. Zhao\n Z. He\n CNNIC\n December 2024", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "SM2 Digital Signature Algorithm for DNSSEC", + "section_title": true, + "ja": "DNSSECのSM2デジタル署名アルゴリズム" + }, + { + "indent": 0, + "text": "Abstract", + "section_title": true, + "ja": "概要" + }, + { + "indent": 3, + "text": "This document specifies the use of the SM2 digital signature algorithm and SM3 hash algorithm for DNS Security (DNSSEC).", + "ja": "このドキュメントは、DNSセキュリティ（DNSSEC）にSM2デジタル署名アルゴリズムとSM3ハッシュアルゴリズムの使用を指定しています。" + }, + { + "indent": 3, + "text": "This document is an Independent Submission to the RFC series and does not have consensus of the IETF community.", + "ja": "このドキュメントは、RFCシリーズへの独立した提出であり、IETFコミュニティのコンセンサスはありません。" + }, + { + "indent": 0, + "text": "Status of This Memo", + "section_title": true, + "ja": "本文書の位置付け" + }, + { + "indent": 3, + "text": "This document is not an Internet Standards Track specification; it is published for informational purposes.", + "ja": "このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。" + }, + { + "indent": 3, + "text": "This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.", + "ja": "これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。RFCエディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。RFCエディターによって公開されることが承認されたドキュメントは、インターネット標準のレベルの候補者ではありません。see Section 2 of RFC 7841." + }, + { + "indent": 3, + "text": "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/rfc9563.", + "ja": "このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9563で取得できます。" + }, + { + "indent": 0, + "text": "Copyright Notice", + "section_title": true, + "ja": "著作権表示" + }, + { + "indent": 3, + "text": "Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.", + "ja": "著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。" + }, + { + "indent": 3, + "text": "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.", + "ja": "このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。" + }, + { + "indent": 0, + "text": "Table of Contents", + "section_title": true, + "ja": "目次" + }, + { + "indent": 3, + "text": "1. Introduction\n2. SM3 DS Records\n3. SM2 Parameters\n4. DNSKEY and RRSIG Resource Records for SM2\n 4.1. DNSKEY Resource Records\n 4.2. RRSIG Resource Records\n5. Support for NSEC3 Denial of Existence\n6. Example\n7. IANA Considerations\n8. Security Considerations\n9. References\n 9.1. Normative References\n 9.2. Informative References\nAuthors' Addresses", + "raw": true, + "toc": true, + "ja": "" + }, + { + "indent": 0, + "text": "1. Introduction", + "section_title": true, + "ja": "1. はじめに" + }, + { + "indent": 3, + "text": "DNSSEC is broadly defined in [RFC4033], [RFC4034], and [RFC4035]. It uses cryptographic keys and digital signatures to provide authentication of DNS data. DNSSEC signature algorithms are registered in the DNSSEC algorithm numbers registry [IANA].", + "ja": "DNSSECは、[RFC4033]、[RFC4034]、および[RFC4035]で広く定義されています。暗号化キーとデジタル署名を使用して、DNSデータの認証を提供します。DNSSEC署名アルゴリズムは、DNSSECアルゴリズム番号レジストリ[IANA]に登録されています。" + }, + { + "indent": 3, + "text": "This document defines the DNSKEY and RRSIG resource records (RRs) of new signing algorithms: SM2 uses elliptic curves over 256-bit prime fields with SM3 hash algorithm. (A description of SM2 can be found in GM/T 0003.2-2012 [GMT-0003.2] or ISO/IEC14888-3:2018 [ISO-IEC14888-3_2018], and a description of SM3 can be found in GM/T 0004-2012 [GMT-0004] or ISO/IEC10118-3:2018 [ISO-IEC10118-3_2018].) This document also defines the DS RR for the SM3 one-way hash algorithm. In the signing algorithm defined in this document, the size of the key for the elliptic curve is matched with the size of the output of the hash algorithm. Both are 256 bits.", + "ja": "このドキュメントでは、新しい署名アルゴリズム：SM2のDNSKEYおよびRRSIGリソースレコード（RRS）を定義します。SM2は、SM3ハッシュアルゴリズムを備えた256ビットプライムフィールドに楕円曲線を使用します。（SM2の説明は、GM/T 0003.2-2012 [GMT-0003.2]またはISO/IEC14888-3：2018 [ISO-IEC14888-3_2018]にあり、SM3の説明はGM/T 0004-にあります。2012 [GMT-0004]またはISO/IEC10118-3：2018 [ISO-IEC10118-3_2018]。）このドキュメントは、SM3一方向ハッシュアルゴリズムのDS RRも定義しています。このドキュメントで定義されている署名アルゴリズムでは、楕円曲線のキーのサイズは、ハッシュアルゴリズムの出力のサイズと一致します。どちらも256ビットです。" + }, + { + "indent": 3, + "text": "Many implementations may not support SM2 signatures and SM3 digests. Section 5.2 of [RFC6840] specifies handling of answers in such cases.", + "ja": "多くの実装は、SM2署名とSM3ダイジェストをサポートしていない場合があります。[RFC6840]のセクション5.2は、そのような場合の回答の処理を指定しています。" + }, + { + "indent": 3, + "text": "Caution: This specification is not a standard and does not have IETF community consensus. It makes use of cryptographic algorithms that are national standards for China, as well as ISO/IEC standards (ISO/ IEC 14888:3-2018 [ISO-IEC14888-3_2018] and ISO/IEC 10118:3-2018 [ISO-IEC10118-3_2018]). Neither the IETF nor the IRTF has analyzed that algorithm for suitability for any given application, and it may contain either intended or unintended weaknesses.", + "ja": "注意：この仕様は標準ではなく、IETFコミュニティのコンセンサスはありません。中国の国家基準である暗号化アルゴリズム、およびISO/IEC標準（ISO/IEC 14888：3-2018 [ISO-IEC14888-3_2018]およびISO/IEC 10118：3-2018 [ISO-IEC10118-3_2018]）。IETFもIRTFも、そのアルゴリズムを特定のアプリケーションへの適合性について分析しておらず、意図されたまたは意図しない弱点のいずれかを含む場合があります。" + }, + { + "indent": 3, + "text": "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.", + "ja": "キーワード「必須」、「必要」、「必須」、「shall」、「shall」、「shill \"of\"、 \"nove\"、 \"becommended\"、 \"becommented\"、 \"may\"、 \"optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。" + }, + { + "indent": 0, + "text": "2. SM3 DS Records", + "section_title": true, + "ja": "2. SM3 DSレコード" + }, + { + "indent": 3, + "text": "The implementation of SM3 in DNSSEC follows the implementation of SHA-256 as specified in [RFC4509] except that the underlying algorithm is SM3 with digest type code 6.", + "ja": "DNSSECでのSM3の実装は、[RFC4509]で指定されているSHA-256の実装に続きます。" + }, + { + "indent": 3, + "text": "The generation of an SM3 hash value is described in Section 5 of [GMT-0004] and generates a 256-bit hash value.", + "ja": "SM3ハッシュ値の生成は、[GMT-0004]のセクション5で説明されており、256ビットハッシュ値を生成します。" + }, + { + "indent": 0, + "text": "3. SM2 Parameters", + "section_title": true, + "ja": "3. SM2パラメーター" + }, + { + "indent": 3, + "text": "Verifying SM2 signatures requires agreement between the signer and the verifier on the parameters used. The SM2 digital signature algorithm has been added to [ISO-IEC14888-3_2018]. The parameters of the curve used in this profile are as follows:", + "ja": "SM2の署名を確認するには、使用されるパラメーターの署名者と検証者との間の合意が必要です。SM2デジタル署名アルゴリズムが[ISO-IEC14888-3_2018]に追加されました。このプロファイルで使用される曲線のパラメーターは次のとおりです。" + }, + { + "indent": 3, + "text": "p = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF\n FFFFFFFF 00000000 FFFFFFFF FFFFFFFF\na = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF\n FFFFFFFF 00000000 FFFFFFFF FFFFFFFC\nb = 28E9FA9E 9D9F5E34 4D5A9E4B CF6509A7\n F39789F5 15AB8F92 DDBCBD41 4D940E93\nxG = 32C4AE2C 1F198119 5F990446 6A39C994\n 8FE30BBF F2660BE1 715A4589 334C74C7\nyG = BC3736A2 F4F6779C 59BDCEE3 6B692153\n D0A9877C C62A4740 02DF32E5 2139F0A0\nn = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF\n 7203DF6B 21C6052B 53BBF409 39D54123", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "4. DNSKEY and RRSIG Resource Records for SM2", + "section_title": true, + "ja": "4. SM2のDNSKEYおよびRRSIGリソースレコード" + }, + { + "indent": 0, + "text": "4.1. DNSKEY Resource Records", + "section_title": true, + "ja": "4.1. DNSKEYリソースレコード" + }, + { + "indent": 3, + "text": "SM2 public keys consist of a single value, called \"P\". In DNSSEC keys, P is a string of 64 octets that represents the uncompressed form of a curve point, \"x | y\". (Conversion of a point to an octet string is described in Section 4.2.8 of [GMT-0003.1].)", + "ja": "SM2パブリックキーは、「P」と呼ばれる単一の値で構成されています。DNSSECキーでは、Pは64個のオクテットの文字列であり、「x | y」の曲線ポイントの非圧縮形式を表します。（ポイントのオクテット文字列への変換は、[GMT-0003.1]のセクション4.2.8で説明されています。）" + }, + { + "indent": 0, + "text": "4.2. RRSIG Resource Records", + "section_title": true, + "ja": "4.2. RRSIGリソースレコード" + }, + { + "indent": 3, + "text": "The SM2 signature is the combination of two non-negative integers, called \"r\" and \"s\". The two integers, each of which is formatted as a simple octet string, are combined into a single longer octet string for DNSSEC as the concatenation \"r | s\". (Conversion of the integers to bit strings is described in Section 4.2.1 of [GMT-0003.1].) Each integer MUST be encoded as 32 octets.", + "ja": "SM2署名は、「R」と「S」と呼ばれる2つの非陰性整数の組み合わせです。それぞれが単純なオクテット弦としてフォーマットされている2つの整数は、連結「r | s」としてDNSSECの長いオクテット文字列に結合されます。（整数の弦への変換は、[GMT-0003.1]のセクション4.2.1で説明されています。）各整数は32オクテットとしてエンコードする必要があります。" + }, + { + "indent": 3, + "text": "Process details are described in Section 6 of [GMT-0003.2].", + "ja": "プロセスの詳細は、[GMT-0003.2]のセクション6で説明されています。" + }, + { + "indent": 3, + "text": "The algorithm number associated with the DNSKEY and RRSIG resource records is 17, which is described in the IANA Considerations section.", + "ja": "DNSKEYおよびRRSIGリソースレコードに関連付けられたアルゴリズム番号は17で、IANAの考慮事項セクションで説明されています。" + }, + { + "indent": 3, + "text": "Conformant implementations that create records to be put into the DNS MAY implement signing and verification for the SM2 digital signature algorithm. Conformant DNSSEC verifiers MAY implement verification for the above algorithm.", + "ja": "DNSに配置されるレコードを作成する適合実装は、SM2デジタル署名アルゴリズムの署名と検証を実装する場合があります。コンフォーマントDNSSEC検証は、上記のアルゴリズムの検証を実装する場合があります。" + }, + { + "indent": 0, + "text": "5. Support for NSEC3 Denial of Existence", + "section_title": true, + "ja": "5. NSEC3存在の拒否のサポート" + }, + { + "indent": 3, + "text": "This document does not define algorithm aliases mentioned in [RFC5155].", + "ja": "このドキュメントは、[RFC5155]で言及されているアルゴリズムエイリアスを定義しません。" + }, + { + "indent": 3, + "text": "A DNSSEC validator that implements the signing algorithms defined in this document MUST be able to validate negative answers in the form of both NSEC and NSEC3 with hash algorithm SHA-1, as defined in [RFC5155]. An authoritative server that does not implement NSEC3 MAY still serve zones that use the signing algorithms defined in this document with NSEC denial of existence.", + "ja": "[RFC5155]で定義されているように、このドキュメントで定義されている署名アルゴリズムを実装するDNSSECバリエーターは、ハッシュアルゴリズムSHA-1を使用してNSECとNSEC3の両方の形で否定的な答えを検証できる必要があります。NSEC3を実装していない権威あるサーバーは、NSECの存在拒否を伴うこのドキュメントで定義されている署名アルゴリズムを使用するゾーンを依然として提供する場合があります。" + }, + { + "indent": 3, + "text": "If using NSEC3, the iterations MUST be 0 and salt MUST be an empty string as recommended in Section 3.1 of [RFC9276].", + "ja": "NSEC3を使用する場合、反復は0でなければならず、[RFC9276]のセクション3.1で推奨されるように、塩は空の文字列でなければなりません。" + }, + { + "indent": 0, + "text": "6. Example", + "section_title": true, + "ja": "6. 例" + }, + { + "indent": 3, + "text": "The following is an example of SM2 keys and signatures in DNS zone file format, including DNSKEY RR, NSEC3PARAM RR, NSEC3 RR with RRSIG RRs, and DS RR.", + "ja": "以下は、DNSKEY RR、NSEC3PARAM RR、RRSIG RRSを備えたNSEC3 RR、DS RRを含むDNSゾーンファイル形式のSM2キーと署名の例です。" + }, + { + "indent": 3, + "text": "Private-key-format: v1.3\nAlgorithm: 17 (SM2SM3)\nPrivateKey: V24tjJgXxp2ykscKRZdT+iuR5J1xRQN+FKoQACmo9fA=\n\nexample. 3600 IN DS 27215 17 6 (\n 86671f82dd872e4ee73647a95dff7fd0af599ff8a43f fa26c9a2593091653c0e\n )\n\nexample. 3600 IN DNSKEY 256 3 17 (\n 7EQ32PTAp+1ac6R9Ze2nfB8pPc2OJqkHSjug\n ALr4SuD9awuQxhfw7wMpiXv7JK4/VwwTrCxJ\n wu+qUuDsgoBK4w==\n ) ; ZSK; alg = SM2SM3 ; key id = 65042\nexample. 3600 IN RRSIG DNSKEY 17 1 3600 (\n 20230901000000 20220901000000 65042 example.\n lF2eq49e62Nn4aT5x8ZI6PdRSTPHPDixZdyl\n lM6GWu4lkRWkpTgWLE4lQK/+qHdNS4DdTd36\n Jsuu0FSO5k48Qg== )\n\nexample. 0 IN NSEC3PARAM 1 0 10 AABBCCDD\nexample. 0 IN RRSIG NSEC3PARAM 17 1 0 (\n 20230901000000 20220901000000 65042 example.\n aqntwEYEJzkVb8SNuJLwdx7f+vivv5IUIeAj )\n\n62KP1QB93KRGR6LM7SEVPJVNG90BLUE8.example. 3600 IN NSEC3 1 1 10\n AABBCCDD (\n GTGVQIILTSSJ8FFO9J6DC8PRTFAEA8G2 NS SOA RRSIG DNSKEY NSEC3PARAM )\n\n62KP1QB93KRGR6LM7SEVPJVNG90BLUE8.example. 3600 IN RRSIG NSEC3 17 2\n 3600 (\n 20230901000000 20220901000000 65042 example.\n FOWLegTgFkFY9vCOo4kHwjEvZ+IL1NMl4s9V\n hVyPOwokd5uOLKeXTP19HIeEtW73WcJ9XNe/ ie/knp7Edo/hxw== )", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[Example_Program] is an example program based on dnspython and gmssl, which supplies key generating, zone signing, zone validating, and DS RR generating functions for convenience.", + "ja": "[example_program]は、dnspythonとgmsslに基づく例プログラムであり、キー生成、ゾーン署名、ゾーン検証、およびDS RR生成機能を提供します。" + }, + { + "indent": 0, + "text": "7. IANA Considerations", + "section_title": true, + "ja": "7. IANAの考慮事項" + }, + { + "indent": 3, + "text": "IANA has registered the following in the \"Digest Algorithms\" registry within the \"DNSSEC Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms\" registry group.", + "ja": "IANAは、「DNSSEC Delogation Signer（DS）Resource Record（RR）Type Digest Algorithms」レジストリグループ内の「Digestアルゴリズム」レジストリに次のことを登録しました。" + }, + { + "indent": 9, + "text": " +=======+=============+==========+===============+\n | Value | Digest Type | Status | Reference |\n +=======+=============+==========+===============+\n | 6 | SM3 | OPTIONAL | This document |\n +-------+-------------+----------+---------------+\n\n Table 1", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "IANA has registered the following in the \"DNS Security Algorithm Numbers\" registry within the \"Domain Name System Security (DNSSEC) Algorithm Numbers\" registry group.", + "ja": "IANAは、「ドメイン名システムセキュリティ（DNSSEC）アルゴリズム番号」レジストリグループ内の「DNSセキュリティアルゴリズム番号」レジストリに以下を登録しました。" + }, + { + "indent": 0, + "text": "+========+================+==========+=========+========+===========+\n| Number | Description | Mnemonic | Zone | Trans. | Reference |\n| | | | Signing | Sec. | |\n+========+================+==========+=========+========+===========+\n| 17 | SM2 signing | SM2SM3 | Y | * | This |\n| | algorithm | | | | document |\n| | with SM3 | | | | |\n| | hashing | | | | |\n| | algorithm | | | | |\n+--------+----------------+----------+---------+--------+-----------+\n\n Table 2", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "* There has been no determination of standardization of the use of this algorithm with Transaction Security.", + "ja": "* トランザクションセキュリティを備えたこのアルゴリズムの使用の標準化の決定はありませんでした。" + }, + { + "indent": 0, + "text": "8. Security Considerations", + "section_title": true, + "ja": "8. セキュリティに関する考慮事項" + }, + { + "indent": 3, + "text": "The security strength of SM2 depends on the size of the key. A longer key provides stronger security strength. The security of ECC-based algorithms is influenced by the curve it uses, too.", + "ja": "SM2のセキュリティ強度は、キーのサイズに依存します。より長いキーは、より強力なセキュリティ強度を提供します。ECCベースのアルゴリズムのセキュリティは、使用する曲線の影響を受けます。" + }, + { + "indent": 3, + "text": "Like any cryptographic algorithm, it may come to pass that a weakness is found in either SM2 or SM3. In this case, the proper remediation is crypto-agility. In the case of DNSSEC, the appropriate approach would be to regenerate appropriate DS, DNSKEY, RRSIG, and NSEC3 records. Care MUST be taken in this situation to permit appropriate rollovers, taking into account record caching. See [RFC7583] for details. A suitable replacement algorithm should be both widely implemented and not known to have weaknesses.", + "ja": "他の暗号化アルゴリズムと同様に、SM2またはSM3のいずれかで弱点が見られることが合格する可能性があります。この場合、適切な修復は暗号特性です。DNSSECの場合、適切なアプローチは、適切なDS、DNSKEY、RRSIG、およびNSEC3レコードを再生することです。この状況では、記録的なキャッシングを考慮して、適切なロールオーバーを許可するように注意する必要があります。詳細については、[RFC7583]を参照してください。適切な交換アルゴリズムは、広く実装されており、弱点があることが知られていない必要があります。" + }, + { + "indent": 3, + "text": "The security considerations listed in [RFC4509] apply here as well.", + "ja": "[RFC4509]にリストされているセキュリティ上の考慮事項もここにも適用されます。" + }, + { + "indent": 0, + "text": "9. References", + "section_title": true, + "ja": "9. 参考文献" + }, + { + "indent": 0, + "text": "9.1. Normative References", + "section_title": true, + "ja": "9.1. 引用文献" + }, + { + "indent": 3, + "text": "[GMT-0003.1]\n Cryptography Standardization Technical Committee of China,\n \"SM2 Public Key Cryptographic Algorithms Based on Elliptic\n Curves Part 1: General\", [In Chinese], GM/T 0003.1-2012,\n March 2012. English translation available at:\n http://www.gmbz.org.cn/\n upload/2024-11-18/1731899501687024253.pdf", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[GMT-0003.2]\n Cryptography Standardization Technical Committee of China,\n \"SM2 Public Key Cryptographic Algorithms Based on Elliptic\n Curves Part 2: Digital Signature Algorithm\", [In Chinese],\n GM/T 0003.2-2012, March 2012. English translation\n available at: http://www.gmbz.org.cn/\n upload/2024-11-18/1731899583359013934.pdf", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[GMT-0004] Cryptography Standardization Technical Committee of China,\n \"SM3 Cryptographic Hash Algorithm\", [In Chinese], GM/\n T 0004-2012, March 2012. English translation available\n at: http://www.gmbz.org.cn/\n upload/2024-11-18/1731899426565012428.pdf.", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[IANA] IANA, \"DNS Security Algorithm Numbers\",\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[ISO-IEC10118-3_2018]\n ISO/IEC, \"IT Security techniques -- Hash-functions -- Part\n 3: Dedicated hash-functions\", ISO/IEC 10118-3:2018,\n October 2018.", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[ISO-IEC14888-3_2018]\n ISO/IEC, \"IT Security techniques -- Digital signatures\n with appendix -- Part 3: Discrete logarithm based\n mechanisms\", ISO/IEC 14888-3:2018, November 2018.", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC2119] Bradner, S., \"Key words for use in RFCs to Indicate\n Requirement Levels\", BCP 14, RFC 2119,\n DOI 10.17487/RFC2119, March 1997,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.\n Rose, \"DNS Security Introduction and Requirements\",\n RFC 4033, DOI 10.17487/RFC4033, March 2005,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.\n Rose, \"Resource Records for the DNS Security Extensions\",\n RFC 4034, DOI 10.17487/RFC4034, March 2005,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.\n Rose, \"Protocol Modifications for the DNS Security\n Extensions\", RFC 4035, DOI 10.17487/RFC4035, March 2005,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC4509] Hardaker, W., \"Use of SHA-256 in DNSSEC Delegation Signer\n (DS) Resource Records (RRs)\", RFC 4509,\n DOI 10.17487/RFC4509, May 2006,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, \"DNS\n Security (DNSSEC) Hashed Authenticated Denial of\n Existence\", RFC 5155, DOI 10.17487/RFC5155, March 2008,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC6840] Weiler, S., Ed. and D. Blacka, Ed., \"Clarifications and\n Implementation Notes for DNS Security (DNSSEC)\", RFC 6840,\n DOI 10.17487/RFC6840, February 2013,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC7583] Morris, S., Ihren, J., Dickinson, J., and W. Mekking,\n \"DNSSEC Key Rollover Timing Considerations\", RFC 7583,\n DOI 10.17487/RFC7583, October 2015,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8174] Leiba, B., \"Ambiguity of Uppercase vs Lowercase in RFC\n 2119 Key Words\", BCP 14, RFC 8174, DOI 10.17487/RFC8174,\n May 2017, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC9276] Hardaker, W. and V. Dukhovni, \"Guidance for NSEC3\n Parameter Settings\", BCP 236, RFC 9276,\n DOI 10.17487/RFC9276, August 2022,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "9.2. Informative References", + "section_title": true, + "ja": "9.2. 参考引用" + }, + { + "indent": 3, + "text": "[Example_Program]\n \"sign and validate dnssec signature with sm2sm3\n algorithm\", commit 6f98c17, April 2023,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "Authors' Addresses", + "section_title": true, + "ja": "著者のアドレス" + }, + { + "indent": 3, + "text": "Cuiling Zhang\nCNNIC\nNo.4 South 4th Street, Zhongguancun\nBeijing\n100190\nChina\nEmail: zhangcuiling@cnnic.cn", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Yukun Liu\nCNNIC\nNo.4 South 4th Street, Zhongguancun\nBeijing\n100190\nChina\nEmail: liuyukun@cnnic.cn", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Feng Leng\nCNNIC\nNo.4 South 4th Street, Zhongguancun\nBeijing\n100190\nChina\nEmail: lengfeng@cnnic.cn", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Qi Zhao\nCNNIC\nNo.4 South 4th Street, Zhongguancun\nBeijing\n100190\nChina\nEmail: zhaoqi@cnnic.cn", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Zheng He\nCNNIC\nNo.4 South 4th Street, Zhongguancun\nBeijing\n100190\nChina\nEmail: hezh@cnnic.cn", + "raw": true, + "ja": "" + } + ] +} \ No newline at end of file diff --git a/data/9000/rfc9610-trans.json b/data/9000/rfc9610-trans.json new file mode 100644 index 000000000..867cb0524 --- /dev/null +++ b/data/9000/rfc9610-trans.json @@ -0,0 +1,1540 @@ +{ + "title": { + "text": "RFC 9610 - JSON Meta Application Protocol (JMAP) for Contacts", + "ja": "RFC 9610 - 連絡先用のJSONメタアプリケーションプロトコル（JMAP）" + }, + "number": 9610, + "created_at": "2024-12-19 23:24:06.652584+09:00", + "updated_by": "", + "contents": [ + { + "indent": 0, + "text": "Internet Engineering Task Force (IETF) N. Jenkins, Ed.\nRequest for Comments: 9610 Fastmail\nCategory: Standards Track December 2024\nISSN: 2070-1721", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "JSON Meta Application Protocol (JMAP) for Contacts", + "section_title": true, + "ja": "連絡先用のJSONメタアプリケーションプロトコル（JMAP）" + }, + { + "indent": 0, + "text": "Abstract", + "section_title": true, + "ja": "概要" + }, + { + "indent": 3, + "text": "This document specifies a data model for synchronising contact data with a server using the JSON Meta Application Protocol (JMAP).", + "ja": "このドキュメントは、JSON Metaアプリケーションプロトコル（JMAP）を使用してサーバーと連絡先データを同期するためのデータモデルを指定します。" + }, + { + "indent": 0, + "text": "Status of This Memo", + "section_title": true, + "ja": "本文書の位置付け" + }, + { + "indent": 3, + "text": "This is an Internet Standards Track document.", + "ja": "これは、インターネット標準トラックドキュメントです。" + }, + { + "indent": 3, + "text": "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.", + "ja": "このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。" + }, + { + "indent": 3, + "text": "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/rfc9610.", + "ja": "このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9610で取得できます。" + }, + { + "indent": 0, + "text": "Copyright Notice", + "section_title": true, + "ja": "著作権表示" + }, + { + "indent": 3, + "text": "Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.", + "ja": "著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。" + }, + { + "indent": 3, + "text": "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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.", + "ja": "このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。" + }, + { + "indent": 0, + "text": "Table of Contents", + "section_title": true, + "ja": "目次" + }, + { + "indent": 3, + "text": "1. Introduction\n 1.1. Notational Conventions\n 1.2. Terminology\n 1.3. Data Model Overview\n 1.4. Addition to the Capabilities Object\n 1.4.1. urn:ietf:params:jmap:contacts\n2. AddressBooks\n 2.1. AddressBook/get\n 2.2. AddressBook/changes\n 2.3. AddressBook/set\n3. ContactCards\n 3.1. ContactCard/get\n 3.2. ContactCard/changes\n 3.3. ContactCard/query\n 3.3.1. Filtering\n 3.3.2. Sorting\n 3.4. ContactCard/queryChanges\n 3.5. ContactCard/set\n 3.6. ContactCard/copy\n4. Examples\n 4.1. Fetching Initial Data\n 4.2. Changing the Default Address Book\n5. Internationalisation Considerations\n6. Security Considerations\n7. IANA Considerations\n 7.1. JMAP Capability Registration for \"contacts\"\n 7.2. JMAP Data Type Registration for \"AddressBook\"\n 7.3. JMAP Data Type Registration for \"ContactCard\"\n 7.4. JMAP Error Codes Registry\n 7.4.1. addressBookHasContents\n 7.5. JSContact Property Registrations\n 7.5.1. id\n 7.5.2. addressBookIds\n 7.5.3. blobId\n8. References\n 8.1. Normative References\n 8.2. Informative References\nAuthor's Address", + "raw": true, + "toc": true, + "ja": "" + }, + { + "indent": 0, + "text": "1. Introduction", + "section_title": true, + "ja": "1. はじめに" + }, + { + "indent": 3, + "text": "The JSON Meta Application Protocol (JMAP) [RFC8620] is a generic protocol for synchronising data, such as mail, calendars, or contacts, between a client and a server. It is optimised for mobile and web environments and aims to provide a consistent interface to different data types.", + "ja": "JSON Meta Application Protocol（JMAP）[RFC8620]は、クライアントとサーバー間のメール、カレンダー、連絡先などのデータを同期するための一般的なプロトコルです。モバイルおよびWeb環境向けに最適化されており、さまざまなデータ型に一貫したインターフェイスを提供することを目的としています。" + }, + { + "indent": 3, + "text": "This specification defines a data model for synchronising contacts between a client and a server using JMAP.", + "ja": "この仕様は、JMAPを使用してクライアントとサーバー間の連絡先を同期するためのデータモデルを定義します。" + }, + { + "indent": 0, + "text": "1.1. Notational Conventions", + "section_title": true, + "ja": "1.1. 表記規則" + }, + { + "indent": 3, + "text": "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.", + "ja": "「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 \"not\"、 \"becommended\"、 \"becommented\"、 \"may\"、 \"optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。" + }, + { + "indent": 3, + "text": "Type signatures, examples, and property descriptions in this document follow the conventions established in Section 1.1 of [RFC8620]. The Id, UnsignedInt, and UTCDate data types defined in Sections 1.2, 1.3, and 1.4 of [RFC8620] are also used in this document.", + "ja": "このドキュメントのタイプシグネチャ、例、およびプロパティの説明は、[RFC8620]のセクション1.1で確立された規則に従っています。[RFC8620]のセクション1.2、1.3、および1.4で定義されているID、UnsignedInt、およびUTCDATEデータ型も、このドキュメントで使用されています。" + }, + { + "indent": 0, + "text": "1.2. Terminology", + "section_title": true, + "ja": "1.2. 用語" + }, + { + "indent": 3, + "text": "The same terminology used in the core JMAP specification (see Section 1.6 of [RFC8620]) is also used in this document.", + "ja": "このドキュメントでは、コアJMAP仕様（[RFC8620]のセクション1.6を参照）で使用されているのと同じ用語も使用されています。" + }, + { + "indent": 3, + "text": "The terms AddressBook and ContactCard (with these specific capitalizations) are used to refer to the data types defined in this document and instances of those data types.", + "ja": "アドレスブックとコンタクトカード（これらの特定の大文字を使用）は、このドキュメントで定義されているデータ型とそれらのデータ型のインスタンスを参照するために使用されます。" + }, + { + "indent": 0, + "text": "1.3. Data Model Overview", + "section_title": true, + "ja": "1.3. データモデルの概要" + }, + { + "indent": 3, + "text": "An Account (see Section 1.6.2 of [RFC8620]) with support for the contact data model contains zero or more AddressBook objects, which is a named collection of zero or more ContactCards. A ContactCard is a representation of a person, company, entity, or a group of such entities in JSContact Card format, as defined in Section 2 of [RFC9553]. Each ContactCard belongs to one or more AddressBooks.", + "ja": "連絡先データモデルのサポートを備えたアカウント（[RFC8620]のセクション1.6.2を参照）には、ゼロ以上のアドレスブックオブジェクトが含まれています。コンタクトカードとは、[RFC9553]のセクション2で定義されているように、JSCONTACTカード形式の個人、会社、エンティティ、またはそのようなエンティティのグループの表現です。各コンタクトカードは、1つ以上のアドレスブックに属します。" + }, + { + "indent": 3, + "text": "In servers with support for JMAP Sharing [RFC9670], users may see and configure sharing of contact data with others. Sharing permissions are managed per AddressBook.", + "ja": "JMAP共有[RFC9670]をサポートするサーバーでは、ユーザーは他の人と連絡先データの共有を見て構成することができます。共有権限は、アドレスブックごとに管理されます。" + }, + { + "indent": 0, + "text": "1.4. Addition to the Capabilities Object", + "section_title": true, + "ja": "1.4. 機能オブジェクトに加えます" + }, + { + "indent": 3, + "text": "The capabilities object is returned as part of the JMAP Session object; see Section 2 of [RFC8620]. This document defines one additional capability URI.", + "ja": "機能オブジェクトは、JMAPセッションオブジェクトの一部として返されます。[RFC8620]のセクション2を参照してください。このドキュメントでは、1つの追加の機能URIを定義します。" + }, + { + "indent": 0, + "text": "1.4.1. urn:ietf:params:jmap:contacts", + "section_title": true, + "ja": "1.4.1. urn：ietf：params：jmap：連絡先" + }, + { + "indent": 3, + "text": "This represents support for the AddressBook and ContactCard data types and associated API methods. The value of this property in the JMAP Session \"capabilities\" property is an empty object.", + "ja": "これは、アドレスブックおよび連絡先データ型および関連するAPIメソッドのサポートを表しています。JMAPセッション「機能」プロパティのこのプロパティの値は、空のオブジェクトです。" + }, + { + "indent": 3, + "text": "The value of this property in an account's \"accountCapabilities\" property is an object that MUST contain the following information on server capabilities and permissions for that account:", + "ja": "アカウントの「accountcapability」プロパティ内のこのプロパティの値は、そのアカウントのサーバー機能と許可に関する次の情報を含める必要があるオブジェクトです。" + }, + { + "indent": 3, + "text": "*maxAddressBooksPerCard*: UnsignedInt|null", + "ja": "*maxaddressbookspercard*：unsignedint | null" + }, + { + "indent": 12, + "text": "The maximum number of AddressBooks (see Section 2) that can be assigned to a single ContactCard object (see Section 3). This MUST be an integer >= 1, or null for no limit (or rather, the limit is always the number of AddressBooks in the account).", + "ja": "単一のコンタクトカードオブジェクト（セクション3を参照）に割り当てることができるアドレスブックの最大数（セクション2を参照）。これは整数> = 1、または制限なしでnullでなければなりません（または、制限は常にアカウント内のアドレスブックの数です）。" + }, + { + "indent": 3, + "text": "*mayCreateAddressBook*: Boolean", + "ja": "*maycreateaddressbook*：boolean" + }, + { + "indent": 12, + "text": "The user may create an AddressBook in this account if, and only if, this is true.", + "ja": "ユーザーは、このアカウントにアドレスブックを作成する場合があります。" + }, + { + "indent": 0, + "text": "2. AddressBooks", + "section_title": true, + "ja": "2. アドレス帳" + }, + { + "indent": 3, + "text": "An AddressBook is a named collection of ContactCards. All ContactCards are associated with one or more AddressBooks.", + "ja": "アドレスブックは、コンタクトカードの名前が付けられたコレクションです。すべてのコンタクトカードは、1つ以上のアドレスブックに関連付けられています。" + }, + { + "indent": 3, + "text": "An *AddressBook* object has the following properties:", + "ja": "*アドレスブック *オブジェクトには次のプロパティがあります。" + }, + { + "indent": 3, + "text": "*id*: Id (immutable; server-set)", + "ja": "*id*：id（inmutable; server-set）" + }, + { + "indent": 12, + "text": "The id of the AddressBook.", + "ja": "アドレスブックのID。" + }, + { + "indent": 3, + "text": "*name*: String", + "ja": "*名前*：文字列" + }, + { + "indent": 12, + "text": "The user-visible name of the AddressBook. This MUST NOT be the empty string and MUST NOT be greater than 255 octets in size when encoded as UTF-8.", + "ja": "アドレスブックのユーザー可視名。これは空の文字列であってはならず、UTF-8としてエンコードされた場合、サイズが255オクテットを超えてはなりません。" + }, + { + "indent": 3, + "text": "*description*: String|null (default: null)", + "ja": "*説明*：string | null（デフォルト：null）" + }, + { + "indent": 12, + "text": "An optional long-form description of the AddressBook that provides context in shared environments where users need more than just the name.", + "ja": "ユーザーが名前以上のものを必要とする共有環境でコンテキストを提供するアドレスブックのオプションの長い形式の説明。" + }, + { + "indent": 3, + "text": "*sortOrder*: UnsignedInt (default: 0)", + "ja": "*SORTORDER*：unsignedint（デフォルト：0）" + }, + { + "indent": 12, + "text": "Defines the sort order of AddressBooks when presented in the client's UI so it is consistent between devices. The number MUST be an integer in the range 0 <= sortOrder < 2^31.", + "ja": "クライアントのUIで提示されたときにアドレス帳の並べ替え順序を定義して、デバイス間で一貫しています。数値は、範囲0 <= sortorder <2^31の整数でなければなりません。" + }, + { + "indent": 12, + "text": "An AddressBook with a lower order is to be displayed before a AddressBook with a higher order in any list of AddressBooks in the client's UI. AddressBooks with equal order should be sorted in alphabetical order by name. The sorting should take into account locale-specific character order convention.", + "ja": "低次のアドレスブックは、クライアントのUIのアドレスブックのリストに高次のアドレスブックの前に表示されます。等しい注文のアドレスブックは、名前でアルファベット順にソートする必要があります。ソートは、ロケール固有のキャラクター順序条約を考慮に入れる必要があります。" + }, + { + "indent": 3, + "text": "*isDefault*: Boolean (server-set)", + "ja": "*isdefault*：boolean（server-set）" + }, + { + "indent": 12, + "text": "This SHOULD be true for exactly one AddressBook in any account and MUST NOT be true for more than one AddressBook within an account. The default AddressBook should be used by clients whenever they need to choose an AddressBook for the user within this account and they do not have any other information on which to make a choice. For example, if the user creates a new contact card, the client may automatically set the card as belonging to the default AddressBook from the user's primary account.", + "ja": "これは、任意のアカウントの1つのアドレスブックに当てはまるはずであり、アカウント内の複数のアドレスブックに当てはまりません。デフォルトのアドレスブックは、このアカウント内のユーザーのアドレスブックを選択する必要がある場合はいつでもクライアントが使用する必要があり、選択するための他の情報がありません。たとえば、ユーザーが新しい連絡先カードを作成した場合、クライアントはユーザーのプライマリアカウントからデフォルトのアドレスブックに属するものとしてカードを自動的に設定できます。" + }, + { + "indent": 3, + "text": "*isSubscribed*: Boolean", + "ja": "*Issubscribed*：boolean" + }, + { + "indent": 12, + "text": "True if the user has indicated they wish to see this AddressBook in their client. This SHOULD default to false for AddressBooks in shared accounts that the user has access to and true for any new AddressBooks created by the user themself.", + "ja": "ユーザーがクライアントにこのアドレスブックを見たいと思っていることを示している場合は、本当です。これは、ユーザーが作成した新しいアドレスブックにアクセスし、真実である共有アカウントのアドレス帳の場合はデフォルトである必要があります。" + }, + { + "indent": 12, + "text": "If false, the AddressBook and its contents SHOULD only be displayed when the user explicitly requests it. The UI may offer to the user the option of subscribing to it.", + "ja": "falseの場合、アドレスブックとその内容は、ユーザーが明示的に要求した場合にのみ表示する必要があります。UIは、ユーザーにサブスクライブするオプションを提供する場合があります。" + }, + { + "indent": 3, + "text": "*shareWith*: Id[AddressBookRights]|null (default: null)", + "ja": "*sharewith*：id [addressbookrights] | null（default：null）" + }, + { + "indent": 12, + "text": "A map of the Principal id (Section 2 of [RFC9670]) to rights for Principals this AddressBook is shared with. The Principal to which this AddressBook belongs MUST NOT be in this set. This is null if the AddressBook is not shared with anyone or if the server does not support [RFC9670]. The value may be modified only if the user has the \"mayShare\" right. The account id for the Principals may be found in the urn:ietf:params:jmap:principals:owner capability of the Account to which the AddressBook belongs.", + "ja": "プリンシパルの権利に対するプリンシパルID（[RFC9670]のセクション2）のマップは、このアドレスブックが共有されています。このアドレスブックが属する校長は、このセットに属してはなりません。これは、アドレスブックが誰とも共有されていない場合、またはサーバーが[RFC9670]をサポートしていない場合にヌルです。値は、ユーザーが「メイシャレ」を正しく持っている場合にのみ変更できます。プリンシパルのアカウントIDは、urn：ietf：params：jmap：principals：addersbookが属するアカウントの所有者能力に記載されている場合があります。" + }, + { + "indent": 3, + "text": "*myRights*: AddressBookRights (server-set)", + "ja": "*MyRights*：AddressBookrights（サーバーセット）" + }, + { + "indent": 12, + "text": "The set of access rights the user has in relation to this AddressBook.", + "ja": "ユーザーがこのアドレスブックに関連して持っているアクセス権のセット。" + }, + { + "indent": 3, + "text": "An *AddressBookRights* object has the following properties:", + "ja": "* addressbookrights *オブジェクトには次のプロパティがあります。" + }, + { + "indent": 3, + "text": "*mayRead*: Boolean", + "ja": "*mayread*：boolean" + }, + { + "indent": 12, + "text": "The user may fetch the ContactCards in this AddressBook.", + "ja": "ユーザーは、このアドレスブックにコンタクトカードを取得できます。" + }, + { + "indent": 3, + "text": "*mayWrite*: Boolean", + "ja": "*メイライト*：ブール" + }, + { + "indent": 12, + "text": "The user may create, modify, or destroy all ContactCards in this AddressBook, or move them to or from this AddressBook.", + "ja": "ユーザーは、このアドレスブックのすべてのコンタクトカードを作成、変更、または破壊するか、このアドレスブックとの間で移動する場合があります。" + }, + { + "indent": 3, + "text": "*mayShare*: Boolean", + "ja": "*Mayshare*：Boolean" + }, + { + "indent": 12, + "text": "The user may modify the \"shareWith\" property for this AddressBook.", + "ja": "ユーザーは、このアドレスブックの「ShareWith」プロパティを変更できます。" + }, + { + "indent": 3, + "text": "*mayDelete*: Boolean", + "ja": "*MayDelete*：boolean" + }, + { + "indent": 12, + "text": "The user may delete the AddressBook itself.", + "ja": "ユーザーは、アドレスブック自体を削除できます。" + }, + { + "indent": 0, + "text": "2.1. AddressBook/get", + "section_title": true, + "ja": "2.1. アドレスbook/get" + }, + { + "indent": 3, + "text": "This is a standard \"/get\" method as described in Section 5.1 of [RFC8620]. The \"ids\" argument may be null to fetch all at once.", + "ja": "これは、[RFC8620]のセクション5.1で説明されている標準「/get」メソッドです。「IDS」引数は、一度にすべてを取得するためにnullになる場合があります。" + }, + { + "indent": 0, + "text": "2.2. AddressBook/changes", + "section_title": true, + "ja": "2.2. アドレスブック/変更" + }, + { + "indent": 3, + "text": "This is a standard \"/changes\" method as described in Section 5.2 of [RFC8620].", + "ja": "これは、[RFC8620]のセクション5.2で説明されている標準の「/変更」メソッドです。" + }, + { + "indent": 0, + "text": "2.3. AddressBook/set", + "section_title": true, + "ja": "2.3. アドレスブック/セット" + }, + { + "indent": 3, + "text": "This is a standard \"/set\" method as described in Section 5.3 of [RFC8620], but with the following additional request arguments:", + "ja": "これは、[RFC8620]のセクション5.3で説明されている標準の「/セット」メソッドですが、次の追加リクエスト引数があります。" + }, + { + "indent": 3, + "text": "*onDestroyRemoveContents*: Boolean (default: false)", + "ja": "*OndestroyRemoveContents*：boolean（デフォルト：false）" + }, + { + "indent": 12, + "text": "If false, any attempt to destroy an AddressBook that still has a ContactCard in it will be rejected with an \"addressBookHasContents\" SetError. If true, any ContactCard that is in the AddressBook will be removed from it, and if such a ContactCard does not belong to any other AddressBook, it will be destroyed.", + "ja": "falseの場合、まだコンタクトカードが含まれているアドレスブックを破壊しようとする試みは、「アドレスbookhascontents」seterrorで拒否されます。真実の場合、アドレスブックにあるコンタクトカードはそこから削除され、そのようなコンタクトカードが他のアドレスブックに属していない場合、破壊されます。" + }, + { + "indent": 3, + "text": "*onSuccessSetIsDefault*: Id|null", + "ja": "*onsuccessetisdefault*：id | null" + }, + { + "indent": 12, + "text": "If an id is given, and all creates, updates, and destroys (if any) succeed without error, the server will try to set this AddressBook as the default. (For references to AddressBook creations, this is equivalent to a creation-reference, so the id will be the creation id prefixed with a \"#\".)", + "ja": "IDが指定され、すべてがエラーなしですべての作成、更新、破壊が成功した場合、サーバーはこのアドレスブックをデフォルトとして設定しようとします。（アドレスブックの作成への参照については、これは作成の参照に相当するため、IDは「＃」が付いた作成IDになります。）" + }, + { + "indent": 3, + "text": "If the id is not found or if the change is not permitted by the server for policy reasons, it MUST be ignored and the current default AddressBook (if any) will remain as such. No error is returned to the client in this case.", + "ja": "IDが見つからない場合、またはポリシーの理由でサーバーによって変更が許可されていない場合、それは無視する必要があり、現在のデフォルトアドレスブック（もしあれば）はそのように残ります。この場合、クライアントにエラーは返されません。" + }, + { + "indent": 3, + "text": "As per Section 5.3 of [RFC8620], if the default AddressBook is successfully changed, any changed objects MUST be reported in either the \"created\" or \"updated\" argument in the response as appropriate, with the server-set value included.", + "ja": "[RFC8620]のセクション5.3によると、デフォルトのアドレスブックが正常に変更された場合、変更されたオブジェクトは、サーバーセット値を含めて、必要に応じて、応答の「作成」または「更新」引数のいずれかで報告する必要があります。" + }, + { + "indent": 3, + "text": "The \"shareWith\" property may only be set by users that have the \"mayShare\" right. When modifying the \"shareWith\" property, the user cannot give a right to a Principal if the Principal did not already have that right and the user making the change also does not have that right. Any attempt to do so MUST be rejected with a \"forbidden\" SetError.", + "ja": "「ShareWith」プロパティは、「Mayshare」が正しいユーザーによってのみ設定される場合があります。「ShareWith」プロパティを変更する場合、プリンシパルがまだその権利を持っていない場合、ユーザーは校長に権利を与えることはできません。そうする試みは、「禁じられた」セットナーで拒否されなければなりません。" + }, + { + "indent": 3, + "text": "Users can subscribe or unsubscribe to an AddressBook by setting the \"isSubscribed\" property. The server MAY forbid users from subscribing to certain AddressBooks even though they have permission to see them, rejecting the update with a \"forbidden\" SetError.", + "ja": "ユーザーは、「ISSUBScribed」プロパティを設定することにより、アドレスブックを購読または登録解除できます。サーバーは、ユーザーが特定のアドレスブックに購読することを禁止する場合があります。" + }, + { + "indent": 3, + "text": "The following extra SetError type is defined for \"destroy\":", + "ja": "次の追加セットエラータイプは、「破壊」用に定義されています。" + }, + { + "indent": 3, + "text": "*addressBookHasContents*:", + "ja": "*addressbookhascontents*：" + }, + { + "indent": 12, + "text": "The AddressBook has at least one ContactCard assigned to it and the \"onDestroyRemoveContents\" argument was false.", + "ja": "アドレスブックには、少なくとも1つのコンタクトカードが割り当てられており、「ondestroyremovocontents」の引数は虚偽でした。" + }, + { + "indent": 0, + "text": "3. ContactCards", + "section_title": true, + "ja": "3. コンタクトカード" + }, + { + "indent": 3, + "text": "A *ContactCard* object contains information about a person, company, or other entity, or represents a group of such entities. It is a JSContact Card object as defined in Section 2 of [RFC9553] with the following additional properties:", + "ja": "A * ContactCard *オブジェクトには、個人、会社、またはその他のエンティティに関する情報が含まれているか、そのようなエンティティのグループを表します。これは、[RFC9553]のセクション2で定義されているJScontactカードオブジェクトであり、次の追加プロパティがあります。" + }, + { + "indent": 3, + "text": "*id*: Id (immutable; server-set)", + "ja": "*id*：id（inmutable; server-set）" + }, + { + "indent": 12, + "text": "The id of the ContactCard. The \"id\" property MAY be different to the ContactCard's \"uid\" property (as defined in Section 2.1.9 of [RFC9553]). However, there MUST NOT be more than one ContactCard with the same uid in an Account.", + "ja": "コンタクトカードのID。「ID」プロパティは、ContactCardの「UID」プロパティとは異なる場合があります（[RFC9553]のセクション2.1.9で定義されています）。ただし、アカウントに同じUIDを持つコンタクトカードが1つ以上ないはずです。" + }, + { + "indent": 3, + "text": "*addressBookIds*: Id[Boolean]", + "ja": "*addressbookids*：id [boolean]" + }, + { + "indent": 12, + "text": "The set of AddressBook ids that this ContactCard belongs to. A card MUST belong to at least one AddressBook at all times (until it is destroyed). The set is represented as an object, with each key being an AddressBook id. The value for each key in the object MUST be true.", + "ja": "このコンタクトカードが属するアドレス帳IDのセット。カードは、常に少なくとも1つのアドレスブックに属している必要があります（破壊されるまで）。セットはオブジェクトとして表され、各キーはアドレス帳IDです。オブジェクト内の各キーの値は真でなければなりません。" + }, + { + "indent": 3, + "text": "For any Media object in the card (see Section 2.6.4 of [RFC9553]), a new property is defined:", + "ja": "カード内のメディアオブジェクト（[RFC9553]のセクション2.6.4を参照）については、新しいプロパティが定義されています。" + }, + { + "indent": 3, + "text": "*blobId*: Id", + "ja": "*Blobid*：id" + }, + { + "indent": 12, + "text": "An id for the Blob representing the binary contents of the resource.", + "ja": "リソースのバイナリコンテンツを表すBLOBのID。" + }, + { + "indent": 3, + "text": "When returning ContactCards, any Media with a URI that uses the \"data:\" URL scheme [RFC2397] SHOULD return a \"blobId\" property and omit the \"uri\" property, as this lets clients load the (potentially large) image file only when needed and avoids the overhead of Base64 encoding. The \"mediaType\" property MUST also be set. Similarly, when creating or updating a ContactCard, clients MAY send a \"blobId\" instead of the \"uri\" property for a Media object.", + "ja": "コンタクトカードを返すとき、「データ：」を使用するURIを持つメディアは、「blobid」プロパティを返し、「uri」プロパティを省略します。Base64エンコーディングのオーバーヘッドが必要で回避されます。「mediatype」プロパティも設定する必要があります。同様に、ContactCardを作成または更新するとき、クライアントはメディアオブジェクトの「URI」プロパティの代わりに「ブロビッド」を送信する場合があります。" + }, + { + "indent": 3, + "text": "A contact card with a \"kind\" property equal to \"group\" represents a group of contacts. Clients often present these separately from other contact cards. The \"members\" property, as defined in Section 2.1.6 of [RFC9553], contains a set of uids (as defined in Section 2.1.9 of [RFC9553]) for other contacts that are the members of this group. Clients should consider the group to contain any ContactCard with a matching uid from any account they have access to that has support for the urn:ietf:params:jmap:contacts capability. Any uid that cannot be found SHOULD be ignored but preserved. For example, suppose a user adds contacts from a shared address book to their private group, then temporarily loses access to this address book. The uids cannot be resolved, so the contacts will disappear from the group. However, if they are given permission to access the data again, the uids will be found and the contacts will reappear.", + "ja": "「グループ」に等しい「種類」プロパティを持つ連絡先カードは、連絡先のグループを表します。多くの場合、クライアントは他の連絡先とは別にこれらを提示します。[RFC9553]のセクション2.1.6で定義されている「メンバー」プロパティには、このグループのメンバーである他の連絡先のUIDS（[RFC9553]のセクション2.1.9で定義されている）のセットが含まれています。クライアントは、urn：ietf：params：jmap：contacts capabilityのサポートを持っているアカウントにアクセスできる任意のアカウントから一致するuidを持つ任意のコンタクトカードを含めることをグループに検討する必要があります。見つけることができないuidは無視する必要がありますが、保存されます。たとえば、ユーザーが共有アドレス帳から個人グループに連絡先を追加してから、このアドレス帳へのアクセスを一時的に失います。UIDを解決できないため、連絡先はグループから消えます。ただし、データに再度アクセスする許可が与えられた場合、UIDSが見つかり、連絡先が再表示されます。" + }, + { + "indent": 0, + "text": "3.1. ContactCard/get", + "section_title": true, + "ja": "3.1. contactCard/get" + }, + { + "indent": 3, + "text": "This is a standard \"/get\" method as described in Section 5.1 of [RFC8620].", + "ja": "これは、[RFC8620]のセクション5.1で説明されている標準「/get」メソッドです。" + }, + { + "indent": 0, + "text": "3.2. ContactCard/changes", + "section_title": true, + "ja": "3.2. ContactCard/変更" + }, + { + "indent": 3, + "text": "This is a standard \"/changes\" method as described in Section 5.2 of [RFC8620].", + "ja": "これは、[RFC8620]のセクション5.2で説明されている標準の「/変更」メソッドです。" + }, + { + "indent": 0, + "text": "3.3. ContactCard/query", + "section_title": true, + "ja": "3.3. 連絡先/クエリ" + }, + { + "indent": 3, + "text": "This is a standard \"/query\" method as described in Section 5.5 of [RFC8620].", + "ja": "これは、[RFC8620]のセクション5.5で説明されている標準の「/クエリ」メソッドです。" + }, + { + "indent": 0, + "text": "3.3.1. Filtering", + "section_title": true, + "ja": "3.3.1. フィルタリング" + }, + { + "indent": 3, + "text": "A *FilterCondition* object has the following properties, any of which may be omitted:", + "ja": "A * FilterCondition *オブジェクトには、次のプロパティがあり、そのいずれかが省略される場合があります。" + }, + { + "indent": 3, + "text": "*inAddressBook*: Id", + "ja": "*inaddressbook*：id" + }, + { + "indent": 12, + "text": "An AddressBook id. A card must be in this address book to match the condition.", + "ja": "アドレス帳です。この条件に合わせて、このアドレス帳にカードが必要です。" + }, + { + "indent": 3, + "text": "*uid*: String", + "ja": "*uid*：文字列" + }, + { + "indent": 12, + "text": "A card must have this string exactly as its uid (as defined in Section 2.1.9 of [RFC9553]) to match.", + "ja": "カードには、[RFC9553]のセクション2.1.9で定義されているように）とまったく同じ文字列が必要です。" + }, + { + "indent": 3, + "text": "*hasMember*: String", + "ja": "*Hasmember*：文字列" + }, + { + "indent": 12, + "text": "A card must have a \"members\" property (as defined in Section 2.1.6 of [RFC9553]) that contains this string as one of the uids in the set to match.", + "ja": "カードには、[RFC9553]のセクション2.1.6で定義されているように、この文字列をセットのUIDの1つとして含む「メンバー」プロパティが必要です。" + }, + { + "indent": 3, + "text": "*kind*: String", + "ja": "*種類*：文字列" + }, + { + "indent": 12, + "text": "A card must have a \"kind\" property (as defined in Section 2.1.4 of [RFC9553]) that equals this string exactly to match.", + "ja": "カードには、[RFC9553]のセクション2.1.4で定義されているように、この文字列に正確に一致するように等しい「種類」プロパティが必要です。" + }, + { + "indent": 3, + "text": "*createdBefore*: UTCDate", + "ja": "*createdbefore*：utcdate" + }, + { + "indent": 12, + "text": "The \"created\" date-time of the ContactCard (as defined in Section 2.1.3 of [RFC9553]) must be before this date-time to match the condition.", + "ja": "コンタクトカードの「作成された」日付時間（[RFC9553]のセクション2.1.3で定義されている）は、この日付の前に条件と一致する必要があります。" + }, + { + "indent": 3, + "text": "*createdAfter*: UTCDate", + "ja": "*createdafter*：utcdate" + }, + { + "indent": 12, + "text": "The \"created\" date-time of the ContactCard (as defined in Section 2.1.3 of [RFC9553]) must be the same or after this date-time to match the condition.", + "ja": "コンタクトカードの「作成された」日付時間（[RFC9553]のセクション2.1.3で定義されている）は、条件と一致するためにこの日付時間と同じまたは後に必要です。" + }, + { + "indent": 3, + "text": "*updatedBefore*: UTCDate", + "ja": "*前に更新*：utcdate" + }, + { + "indent": 12, + "text": "The \"updated\" date-time of the ContactCard (as defined in Section 2.1.10 of [RFC9553]) must be before this date-time to match the condition.", + "ja": "コンタクトカードの「更新された」日付時間（[RFC9553]のセクション2.1.10で定義されている）は、この日付の前に条件に一致する必要があります。" + }, + { + "indent": 3, + "text": "*updatedAfter*: UTCDate", + "ja": "*Affter*を更新：utcdate" + }, + { + "indent": 12, + "text": "The \"updated\" date-time of the ContactCard (as defined in Section 2.1.10 of [RFC9553]) must be the same or after this date-time to match the condition.", + "ja": "コンタクトカードの「更新された」日付時間（[RFC9553]のセクション2.1.10で定義されている）は、条件と一致するためにこの日付時間と同じか、後に同じでなければなりません。" + }, + { + "indent": 3, + "text": "*text*: String", + "ja": "*テキスト*：文字列" + }, + { + "indent": 12, + "text": "A card matches this condition if the text matches with text in the card.", + "ja": "テキストがカード内のテキストと一致する場合、カードはこの状態と一致します。" + }, + { + "indent": 3, + "text": "*name*: String", + "ja": "*名前*：文字列" + }, + { + "indent": 12, + "text": "A card matches this condition if the value of any NameComponent in the \"name\" property or the \"full\" property in the \"name\" property of the card (as defined in Section 2.2.1.2 of [RFC9553]) matches the value.", + "ja": "カードの「名前」プロパティのnameComponentの値またはカードの「名前」プロパティ（[RFC9553]のセクション2.2.1.2で定義されている）の「完全な」プロパティの値が値に一致する場合、カードはこの条件に一致します。" + }, + { + "indent": 3, + "text": "*name/given*: String", + "ja": "*名前/指定*：文字列" + }, + { + "indent": 12, + "text": "A card matches this condition if the value of a NameComponent with kind \"given\" inside the \"name\" property of the card (as defined in Section 2.2.1.2 of [RFC9553]) matches the value.", + "ja": "カードの「名前」プロパティ内に「与えられた」種類（[RFC9553]のセクション2.2.1.2で定義されている）が値と一致する場合、カードはこの状態と一致します。" + }, + { + "indent": 3, + "text": "*name/surname*: String", + "ja": "*名前/姓*：文字列" + }, + { + "indent": 12, + "text": "A card matches this condition if the value of a NameComponent with kind \"surname\" inside the \"name\" property of the card (as defined in Section 2.2.1.2 of [RFC9553]) matches the value.", + "ja": "カードの「名前」プロパティ内の「姓」（[RFC9553]のセクション2.2.1.2で定義されている）が値と一致する場合、カードはこの状態と一致します。" + }, + { + "indent": 3, + "text": "*name/surname2*: String", + "ja": "*name/surname2*：文字列" + }, + { + "indent": 12, + "text": "A card matches this condition if the value of a NameComponent with kind \"surname2\" inside the \"name\" property of the card (as defined in Section 2.2.1.2 of [RFC9553]) matches the value.", + "ja": "カードの「surname2」の「surname2」がある場合（[rfc9553]セクション2.2.1.2で定義されている）、namecomponentの値が[rfc9553]のセクション2.2.1.2で定義されている）の場合、この状態と一致します。" + }, + { + "indent": 3, + "text": "*nickname*: String", + "ja": "*ニックネーム*：文字列" + }, + { + "indent": 12, + "text": "A card matches this condition if the \"name\" of any Nickname in the \"nicknames\" property of the card (as defined in Section 2.2.2 of [RFC9553]) matches the value.", + "ja": "カードの「ニックネーム」プロパティ（[RFC9553]のセクション2.2.2で定義）のニックネームの「名前」が値に一致する場合、カードはこの状態と一致します。" + }, + { + "indent": 3, + "text": "*organization*: String", + "ja": "*組織*：文字列" + }, + { + "indent": 12, + "text": "A card matches this condition if the \"name\" of any Organization in the \"organizations\" property of the card (as defined in Section 2.2.3 of [RFC9553]) matches the value.", + "ja": "カードの「組織」プロパティ（[RFC9553]のセクション2.2.3で定義）の組織の「名前」が値に一致する場合、カードはこの条件と一致します。" + }, + { + "indent": 3, + "text": "*email*: String", + "ja": "*電子メール*：文字列" + }, + { + "indent": 12, + "text": "A card matches this condition if the \"address\" or \"label\" of any EmailAddress in the \"emails\" property of the card (as defined in Section 2.3.1 of [RFC9553]) matches the value.", + "ja": "カードの「電子メール」プロパティ（[RFC9553]のセクション2.3.1で定義されている）の電子メールアドレスの「アドレス」または「ラベル」が値に一致する場合、カードはこの状態と一致します。" + }, + { + "indent": 3, + "text": "*phone*: String", + "ja": "*電話*：文字列" + }, + { + "indent": 12, + "text": "A card matches this condition if the \"number\" or \"label\" of any Phone in the \"phones\" property of the card (as defined in Section 2.3.3 of [RFC9553]) matches the value.", + "ja": "カードの「電話」プロパティ（[RFC9553]のセクション2.3.3で定義されている）の任意の電話の「番号」または「ラベル」が値に一致する場合、カードはこの状態と一致します。" + }, + { + "indent": 3, + "text": "*onlineService*: String", + "ja": "*onlineservice*：string" + }, + { + "indent": 12, + "text": "A card matches this condition if the \"service\", \"uri\", \"user\", or \"label\" of any OnlineService in the \"onlineServices\" property of the card (as defined in Section 2.3.2 of [RFC9553]) matches the value.", + "ja": "カードの「サービス」、「uri」、「user」、または「onlineservices」プロパティの任意の任意の任意の任意の任意の条件（[rfc9553]のセクション2.3.2で定義）が一致する場合、カードはこの状態に一致します。価値。" + }, + { + "indent": 3, + "text": "*address*: String", + "ja": "*アドレス*：文字列" + }, + { + "indent": 12, + "text": "A card matches this condition if the value of any AddressComponent in the \"addresses\" property or the \"full\" property in the \"addresses\" property of the card (as defined in Section 2.5.1 of [RFC9553]) matches the value.", + "ja": "カードの「アドレス」プロパティ内のaddressComponentの値または「[RFC9553]のセクション2.5.1で定義されている」の「アドレス」プロパティの「アドレス」プロパティの値が値に一致する場合、カードはこの条件に一致します。" + }, + { + "indent": 3, + "text": "*note*: String", + "ja": "*注*：文字列" + }, + { + "indent": 12, + "text": "A card matches this condition if the \"note\" of any Note in the \"notes\" property of the card (as defined in Section 2.8.3 of [RFC9553]) matches the value.", + "ja": "カードの「ノート」プロパティ（[RFC9553]のセクション2.8.3で定義されている）が値に一致する場合、カードはこの状態と一致します。" + }, + { + "indent": 3, + "text": "If zero properties are specified on the FilterCondition, the condition MUST always evaluate to true. If multiple properties are specified, ALL must apply for the condition to be true (it is equivalent to splitting the object into one-property conditions and making them all the child of an AND filter operator).", + "ja": "フィルターコンディションでゼロプロパティが指定されている場合、条件は常にtrueに評価する必要があります。複数のプロパティが指定されている場合、すべてが真であるようにすべてを適用する必要があります（オブジェクトを1つのプロパティ条件に分割し、それらをすべてのフィルター演算子の子にすることに相当します）。" + }, + { + "indent": 3, + "text": "The exact semantics for matching String fields is deliberately not defined to allow for flexibility in indexing implementation, subject to the following:", + "ja": "文字列フィールドを一致させる正確なセマンティクスは、以下に対応するインデックス作成の実装の柔軟性を可能にするために意図的に定義されていません。" + }, + { + "indent": 6, + "text": "* Text SHOULD be matched in a case-insensitive manner.", + "ja": "* テキストは、ケースに依存しない方法で一致する必要があります。" + }, + { + "indent": 6, + "text": "* Text contained in either (but matched) single or double quotes SHOULD be treated as a phrase search. That is, a match is required for that exact sequence of words, excluding the surrounding quotation marks. Use \\\", \\', and \\\\ to match a literal \", ', and \\ respectively in a phrase.", + "ja": "* どちらか（ただし一致した）または二重引用符に含まれるテキストは、フレーズ検索として扱う必要があります。つまり、周囲の引用符を除く、その正確な一連の単語に一致する必要があります。\\ \"、\\ '、および\\\\を使用して、文字通り\"、'、および\\をフレーズでそれぞれ一致させます。" + }, + { + "indent": 6, + "text": "* Outside of a phrase, whitespace SHOULD be treated as dividing separate tokens that may be searched for separately in the contact, but MUST all be present for the contact to match the filter.", + "ja": "* フレーズの外では、ホワイトスペースは、接触で別々に検索される可能性のある別々のトークンとして扱われる必要がありますが、フィルターと一致するように接触するためにはすべて存在する必要があります。" + }, + { + "indent": 6, + "text": "* Tokens MAY be matched on a whole-word basis using stemming (e.g., a text search for bus would match \"buses\", but not \"business\").", + "ja": "* トークンは、ステムを使用して全単語ベースで一致する場合があります（たとえば、バスのテキスト検索は「バス」と一致しますが、「ビジネス」ではありません）。" + }, + { + "indent": 0, + "text": "3.3.2. Sorting", + "section_title": true, + "ja": "3.3.2. ソート" + }, + { + "indent": 3, + "text": "The following values for the \"property\" field on the Comparator object MUST be supported for sorting:", + "ja": "コンパレータオブジェクトの「プロパティ」フィールドの次の値は、ソートのためにサポートする必要があります。" + }, + { + "indent": 6, + "text": "* \"created\" - The \"created\" date on the ContactCard.", + "ja": "* 「作成」 - コンタクトカードの「作成された」日付。" + }, + { + "indent": 6, + "text": "* \"updated\" - The \"updated\" date on the ContactCard.", + "ja": "* 「更新」 - 連絡先カードの「更新された」日付。" + }, + { + "indent": 3, + "text": "The following values for the \"property\" field on the Comparator object SHOULD be supported for sorting:", + "ja": "コンパレータオブジェクトの「プロパティ」フィールドの次の値は、ソートのためにサポートする必要があります。" + }, + { + "indent": 6, + "text": "* \"name/given\" - The value of the first NameComponent in the \"name\" property whose \"kind\" is \"given\".", + "ja": "* 「名前/与えられた」 - 「dign」プロパティの最初のnamecomponentの値は、「Dism」が与えられます。" + }, + { + "indent": 6, + "text": "* \"name/surname\" - The value of the first NameComponent in the \"name\" property whose \"kind\" is \"surname\".", + "ja": "* 「name/surname」 - 「姓」が「姓」である「name」プロパティの最初のnamecomponentの値。" + }, + { + "indent": 6, + "text": "* \"name/surname2\" - The value of the first NameComponent in the \"name\" property whose \"kind\" is \"surname2\".", + "ja": "* 「name/surname2」 - 「surname2」である「name」プロパティの最初のnamecomponentの値。" + }, + { + "indent": 0, + "text": "3.4. ContactCard/queryChanges", + "section_title": true, + "ja": "3.4. ContactCard/QueryChanges" + }, + { + "indent": 3, + "text": "This is a standard \"/queryChanges\" method as described in Section 5.6 of [RFC8620].", + "ja": "これは、[RFC8620]のセクション5.6で説明されている標準の「/QueryChanges」メソッドです。" + }, + { + "indent": 0, + "text": "3.5. ContactCard/set", + "section_title": true, + "ja": "3.5. contactcard/set" + }, + { + "indent": 3, + "text": "This is a standard \"/set\" method as described in Section 5.3 of [RFC8620].", + "ja": "これは、[RFC8620]のセクション5.3で説明されている標準の「/セット」メソッドです。" + }, + { + "indent": 3, + "text": "To set a new photo, the file must first be uploaded using the upload mechanism as described in Section 6.1 of [RFC8620]. This will give the client a valid blobId, size, and type to use. The server MUST reject attempts to set a file that is not a recognised image type as the photo for a card.", + "ja": "新しい写真を設定するには、[RFC8620]のセクション6.1で説明されているように、最初にアップロードメカニズムを使用してファイルをアップロードする必要があります。これにより、クライアントに使用する有効なブロビッド、サイズ、タイプが得られます。サーバーは、カードの写真として認識されている画像タイプではないファイルを設定しようとする試みを拒否する必要があります。" + }, + { + "indent": 0, + "text": "3.6. ContactCard/copy", + "section_title": true, + "ja": "3.6. 連絡先/コピー" + }, + { + "indent": 3, + "text": "This is a standard \"/copy\" method as described in Section 5.4 of [RFC8620].", + "ja": "これは、[RFC8620]のセクション5.4で説明されている標準の「/コピー」メソッドです。" + }, + { + "indent": 0, + "text": "4. Examples", + "section_title": true, + "ja": "4. 例" + }, + { + "indent": 3, + "text": "For brevity, only the \"methodCalls\" property of the Request object and the \"methodResponses\" property of the Response object is shown in the following examples.", + "ja": "簡潔にするために、リクエストオブジェクトの「メソッドコール」プロパティと応答オブジェクトの「メソッドレスポンズ」プロパティのみを次の例に示します。" + }, + { + "indent": 0, + "text": "4.1. Fetching Initial Data", + "section_title": true, + "ja": "4.1. 初期データを取得します" + }, + { + "indent": 3, + "text": "A user has authenticated and the client has fetched the JMAP Session object. It finds a single Account with the \"urn:ietf:params:jmap:contacts\" capability with id \"a0x9\" and wants to fetch all the address books and contacts. It might make the following request:", + "ja": "ユーザーが認証されており、クライアントはJMAPセッションオブジェクトを取得しました。「urn：ietf：params：jmap：contacts \"capability with id\" a0x9」を使用した単一のアカウントを見つけ、すべてのアドレス帳と連絡先を取得したいと考えています。次のリクエストを行う可能性があります。" + }, + { + "indent": 3, + "text": "[\n [\"AddressBook/get\", {\n \"accountId\": \"a0x9\"\n }, \"0\"],\n [\"ContactCard/get\", {\n \"accountId\": \"a0x9\"\n }, \"1\"]\n]", + "raw": true, + "ja": "" + }, + { + "indent": 13, + "text": "Figure 1: \"methodCalls\" Property of a JMAP Request", + "ja": "図1：JMAP要求の「MethodCalls」プロパティ" + }, + { + "indent": 3, + "text": "The server might respond with something like:", + "ja": "サーバーは次のようなもので応答する場合があります。" + }, + { + "indent": 3, + "text": "[\n [\"AddressBook/get\", {\n \"accountId\": \"a0x9\",\n \"list\": [{\n \"id\": \"062adcfa-105d-455c-bc60-6db68b69c3f3\",\n \"name\": \"Personal\",\n \"description\": null,\n \"sortOrder\": 0,\n \"isDefault\": true,\n \"isSubscribed\": true,\n \"shareWith\": {\n \"3f1502e0-63fe-4335-9ff3-e739c188f5dd\": {\n \"mayRead\": true,\n \"mayWrite\": false,\n \"mayShare\": false,\n \"mayDelete\": false\n }\n },\n \"myRights\": {\n \"mayRead\": true,\n \"mayWrite\": true,\n \"mayShare\": true,\n \"mayDelete\": false\n }\n }, {\n \"id\": \"cd40089d-35f9-4fd7-980b-ba3a9f1d74fe\",\n \"name\": \"Autosaved\",\n \"description\": null,\n \"sortOrder\": 1,\n \"isDefault\": false,\n \"isSubscribed\": true,\n \"shareWith\": null,\n \"myRights\": {\n \"mayRead\": true,\n \"mayWrite\": true,\n \"mayShare\": true,\n \"mayDelete\": false\n }\n }],\n \"notFound\": [],\n \"state\": \"~4144\"\n }, \"0\"],\n [\"ContactCard/get\", {\n \"accountId\": \"a0x9\",\n \"list\": [{\n \"id\": \"3\",\n \"addressBookIds\": {\n \"062adcfa-105d-455c-bc60-6db68b69c3f3\": true\n },\n \"name\": {\n \"components\": [\n { \"kind\": \"given\", \"value\": \"Joe\" },\n { \"kind\": \"surname\", \"value\": \"Bloggs\" }\n ],\n \"isOrdered\": true\n },\n \"emails\": {\n \"0\": {\n \"contexts\": {\n \"private\": true\n },\n \"address\": \"joe.bloggs@example.com\"\n }\n }\n }],\n \"notFound\": [],\n \"state\": \"ewarbckaqJ::112\"\n }, \"1\"]\n]", + "raw": true, + "ja": "" + }, + { + "indent": 10, + "text": "Figure 2: \"methodResponses\" Property of a JMAP Response", + "ja": "図2：JMAP応答の「MethodSponses」プロパティ" + }, + { + "indent": 0, + "text": "4.2. Changing the Default Address Book", + "section_title": true, + "ja": "4.2. デフォルトのアドレス帳を変更します" + }, + { + "indent": 3, + "text": "The client tries to change the default address book from \"Personal\" to \"Autosaved\" (and makes no other change):", + "ja": "クライアントは、デフォルトのアドレス帳を「個人」から「オートセーブド」に変更しようとします（そして、他の変更はありません）：" + }, + { + "indent": 3, + "text": "[\n [\"AddressBook/set\", {\n \"accountId\": \"a0x9\",\n \"onSuccessSetIsDefault\": \"cd40089d-35f9-4fd7-980b-ba3a9f1d74fe\"\n }, \"0\"]\n]", + "raw": true, + "ja": "" + }, + { + "indent": 13, + "text": "Figure 3: \"methodCalls\" Property of a JMAP Request", + "ja": "図3：JMAP要求の「MethodCalls」プロパティ" + }, + { + "indent": 3, + "text": "The server allows the change, returning the following response:", + "ja": "サーバーは変更を許可し、次の応答を返します。" + }, + { + "indent": 3, + "text": "[\n [\"AddressBook/set\", {\n \"accountId\": \"a0x9\",\n \"updated\": {\n \"cd40089d-35f9-4fd7-980b-ba3a9f1d74fe\": {\n \"isDefault\": true\n },\n \"062adcfa-105d-455c-bc60-6db68b69c3f3\": {\n \"isDefault\": false\n },\n \"oldState\": \"~4144\",\n \"newState\": \"~4148\"\n }\n }, \"0\"]\n]", + "raw": true, + "ja": "" + }, + { + "indent": 10, + "text": "Figure 4: \"methodResponses\" Property of a JMAP Response", + "ja": "図4：JMAP応答の「MethodSponses」プロパティ" + }, + { + "indent": 0, + "text": "5. Internationalisation Considerations", + "section_title": true, + "ja": "5. 国際化の考慮事項" + }, + { + "indent": 3, + "text": "Experience has shown that unrestricted use of Unicode can lead to problems such as inconsistent rendering, users reading text and interpreting it differently than intended, and unexpected results when copying text from one location to another. Servers MAY choose to mitigate this by restricting the set of characters allowed in otherwise unconstrained String fields. The FreeformClass, as documented in Section 4.3 of [RFC8264], might be a good starting point for this.", + "ja": "経験によると、Unicodeの無制限の使用は、一貫性のないレンダリング、ユーザーがテキストを読んで、意図したものとは異なる方法で解釈するなどの問題につながる可能性があり、ある場所から別の場所にテキストをコピーする際の予期しない結果が得られることが示されています。サーバーは、制約のない文字列フィールドで許可されている文字のセットを制限することにより、これを軽減することを選択できます。[RFC8264]のセクション4.3に記載されているフリーフォームクラスは、これの良い出発点かもしれません。" + }, + { + "indent": 3, + "text": "Attempts to set a value containing code points outside of the permissible set can be handled in a few ways by the server. The server could choose to strip the forbidden characters or replace them with U+FFFD (the Unicode replacement character) and store the resulting string. This is likely to be appropriate for non-printable characters -- such as the \"Control Codes\" defined in Section 23.1 (https://www.unicode.org/versions/latest/core-spec/chapter-23/#G20365) of [UNICODE], excluding newline (U+000A), carriage return (U+000D), and tab (U+0009) -- that can end up in data accidentally due to copy-and-paste issues but are invisible to the end user. JMAP allows the server to transform data on create/update as long as any changed properties are returned to the client in the \"/set\" response so it knows what has changed, as per Section 5.3 of [RFC8620]. Alternatively, the server MAY just reject the create/update with an \"invalidProperties\" SetError.", + "ja": "許容セットの外側にコードポイントを含む値を設定する試みは、サーバーによっていくつかの方法で処理できます。サーバーは、禁止された文字を剥がすか、u+fffd（Unicode置換文字）に置き換えて、結果の文字列を保存することを選択できます。これは、セクション23.1（https://www.unicode.org/versions/latest/core-pec/chapter-23/#g20365）で定義されている「コントロールコード」など、印刷できない文字に適している可能性があります。[Unicode]、Newline（U+000a）、キャリッジリターン（U+000D）、およびタブ（U+0009）を除く - コピーアンドパスティの問題により誤ってデータになりますが、エンドユーザー。JMAPを使用すると、[RFC8620]のセクション5.3によると、変更されたプロパティが「/set」応答でクライアントに返される限り、サーバーは作成/更新のデータを変換できます。あるいは、サーバーは、「nivalidproperties」setErrorで作成/更新を拒否するだけです。" + }, + { + "indent": 0, + "text": "6. Security Considerations", + "section_title": true, + "ja": "6. セキュリティに関する考慮事項" + }, + { + "indent": 3, + "text": "All security considerations of JMAP [RFC8620] apply to this specification. Additional considerations specific to the data types and functionality introduced by this document are described in the following subsection.", + "ja": "JMAP [RFC8620]のすべてのセキュリティ上の考慮事項は、この仕様に適用されます。このドキュメントで導入されたデータ型と機能に固有の追加の考慮事項については、以下のサブセクションで説明します。" + }, + { + "indent": 3, + "text": "Contacts consist almost entirely of private, personally identifiable information, and represent the social connections of users. Privacy leaks can have real world consequences, and contact servers and clients MUST be mindful of the need to keep all data secure.", + "ja": "連絡先は、ほぼ完全にプライベートで個人的に識別可能な情報から構成され、ユーザーの社会的つながりを表しています。プライバシーリークは現実世界の結果をもたらす可能性があり、連絡先サーバーとクライアントは、すべてのデータを安全に保つ必要性に留意する必要があります。" + }, + { + "indent": 3, + "text": "Servers MUST enforce the Access Control Lists (ACLs) set on address books to ensure only authorised data is shared.", + "ja": "サーバーは、アドレス帳に設定されたアクセス制御リスト（ACLS）を実施して、認定データのみが共有されるようにする必要があります。" + }, + { + "indent": 0, + "text": "7. IANA Considerations", + "section_title": true, + "ja": "7. IANAの考慮事項" + }, + { + "indent": 0, + "text": "7.1. JMAP Capability Registration for \"contacts\"", + "section_title": true, + "ja": "7.1. 「連絡先」のJMAP機能登録" + }, + { + "indent": 3, + "text": "IANA has registered \"contacts\" in the \"JMAP Capabilities\" registry as follows:", + "ja": "IANAは、次のように「JMAP機能」レジストリに「連絡先」を登録しています。" + }, + { + "indent": 3, + "text": "Capability Name:", + "ja": "機能名：" + }, + { + "indent": 12, + "text": "urn:ietf:params:jmap:contacts", + "ja": "urn：ietf：params：jmap：連絡先" + }, + { + "indent": 3, + "text": "Intended Use:", + "ja": "使用目的：" + }, + { + "indent": 12, + "text": "common", + "ja": "一般" + }, + { + "indent": 3, + "text": "Change Controller:", + "ja": "Change Controller：" + }, + { + "indent": 12, + "text": "IETF", + "ja": "IETF" + }, + { + "indent": 3, + "text": "Security and Privacy Considerations:", + "ja": "セキュリティとプライバシーの考慮事項：" + }, + { + "indent": 12, + "text": "this document, Section 6", + "ja": "このドキュメント、セクション6" + }, + { + "indent": 3, + "text": "Reference:", + "ja": "参照：" + }, + { + "indent": 12, + "text": "this document", + "ja": "このドキュメント" + }, + { + "indent": 0, + "text": "7.2. JMAP Data Type Registration for \"AddressBook\"", + "section_title": true, + "ja": "7.2. JMAPデータ型「アドレスブック」の登録" + }, + { + "indent": 3, + "text": "IANA has registered \"AddressBook\" in the \"JMAP Data Types\" registry as follows:", + "ja": "IANAは、次のように「JMAPデータ型」レジストリに「アドレスブック」を登録しています。" + }, + { + "indent": 3, + "text": "Type Name:", + "ja": "タイプ名：" + }, + { + "indent": 12, + "text": "AddressBook", + "ja": "アドレスブック" + }, + { + "indent": 3, + "text": "Can Reference Blobs:", + "ja": "塊を参照できます：" + }, + { + "indent": 12, + "text": "No", + "ja": "いいえ" + }, + { + "indent": 3, + "text": "Can Use for State Change:", + "ja": "状態の変更に使用できます：" + }, + { + "indent": 12, + "text": "Yes", + "ja": "はい" + }, + { + "indent": 3, + "text": "Capability:", + "ja": "能力：" + }, + { + "indent": 12, + "text": "urn:ietf:params:jmap:contacts", + "ja": "urn：ietf：params：jmap：連絡先" + }, + { + "indent": 3, + "text": "Reference:", + "ja": "参照：" + }, + { + "indent": 12, + "text": "this document", + "ja": "このドキュメント" + }, + { + "indent": 0, + "text": "7.3. JMAP Data Type Registration for \"ContactCard\"", + "section_title": true, + "ja": "7.3. JMAPデータ型「ContactCard」の登録" + }, + { + "indent": 3, + "text": "IANA has registered \"ContactCard\" in the \"JMAP Data Types\" registry as follows:", + "ja": "IANAは、次のように「JMAPデータ型」レジストリに「ContactCard」を登録しています。" + }, + { + "indent": 3, + "text": "Type Name:", + "ja": "タイプ名：" + }, + { + "indent": 12, + "text": "ContactCard", + "ja": "ContactCard" + }, + { + "indent": 3, + "text": "Can Reference Blobs:", + "ja": "塊を参照できます：" + }, + { + "indent": 12, + "text": "Yes", + "ja": "はい" + }, + { + "indent": 3, + "text": "Can Use for State Change:", + "ja": "状態の変更に使用できます：" + }, + { + "indent": 12, + "text": "Yes", + "ja": "はい" + }, + { + "indent": 3, + "text": "Capability:", + "ja": "能力：" + }, + { + "indent": 12, + "text": "urn:ietf:params:jmap:contacts", + "ja": "urn：ietf：params：jmap：連絡先" + }, + { + "indent": 3, + "text": "Reference:", + "ja": "参照：" + }, + { + "indent": 12, + "text": "this document", + "ja": "このドキュメント" + }, + { + "indent": 0, + "text": "7.4. JMAP Error Codes Registry", + "section_title": true, + "ja": "7.4. JMAPエラーコードレジストリ" + }, + { + "indent": 3, + "text": "The following subsection has registered a new error code in the \"JMAP Error Codes\" registry, as defined in Section 9 of [RFC8620].", + "ja": "次のサブセクションは、[RFC8620]のセクション9で定義されているように、「JMAPエラーコード」レジストリに新しいエラーコードを登録しています。" + }, + { + "indent": 0, + "text": "7.4.1. addressBookHasContents", + "section_title": true, + "ja": "7.4.1. アドレスbookhascontents" + }, + { + "indent": 3, + "text": "JMAP Error Code:", + "ja": "JMAPエラーコード：" + }, + { + "indent": 12, + "text": "addressBookHasContents", + "ja": "アドレスbookhascontents" + }, + { + "indent": 3, + "text": "Intended Use:", + "ja": "使用目的：" + }, + { + "indent": 12, + "text": "common", + "ja": "一般" + }, + { + "indent": 3, + "text": "Change Controller:", + "ja": "Change Controller：" + }, + { + "indent": 12, + "text": "IETF", + "ja": "IETF" + }, + { + "indent": 3, + "text": "Description:", + "ja": "説明：" + }, + { + "indent": 12, + "text": "The AddressBook has at least one ContactCard assigned to it, and the \"onDestroyRemoveContents\" argument was false.", + "ja": "アドレスブックには、少なくとも1つのコンタクトカードが割り当てられており、「destroyremovocontents」の引数は虚偽でした。" + }, + { + "indent": 3, + "text": "Reference:", + "ja": "参照：" + }, + { + "indent": 12, + "text": "This document, Section 2.3", + "ja": "このドキュメント、セクション2.3" + }, + { + "indent": 0, + "text": "7.5. JSContact Property Registrations", + "section_title": true, + "ja": "7.5. jScontactプロパティ登録" + }, + { + "indent": 3, + "text": "IANA has registered the following additional properties in the \"JSContact Properties\" registry, as defined in Section 3 of [RFC9553].", + "ja": "IANAは、[RFC9553]のセクション3で定義されているように、「JScontactプロパティ」レジストリに次の追加プロパティを登録しています。" + }, + { + "indent": 0, + "text": "7.5.1. id", + "section_title": true, + "ja": "7.5.1. id" + }, + { + "indent": 3, + "text": "Property Name:", + "ja": "プロパティ名：" + }, + { + "indent": 12, + "text": "id", + "ja": "id" + }, + { + "indent": 3, + "text": "Property Type:", + "ja": "プロパティタイプ：" + }, + { + "indent": 12, + "text": "not applicable", + "ja": "適用できない" + }, + { + "indent": 3, + "text": "Property Context:", + "ja": "プロパティコンテキスト：" + }, + { + "indent": 12, + "text": "Card", + "ja": "カード" + }, + { + "indent": 3, + "text": "Intended Usage:", + "ja": "意図された使用法：" + }, + { + "indent": 12, + "text": "reserved", + "ja": "予約済み" + }, + { + "indent": 3, + "text": "Since Version:", + "ja": "バージョン以来：" + }, + { + "indent": 12, + "text": "1.0", + "ja": "1.0" + }, + { + "indent": 3, + "text": "Change Controller:", + "ja": "Change Controller：" + }, + { + "indent": 12, + "text": "IETF", + "ja": "IETF" + }, + { + "indent": 3, + "text": "Reference:", + "ja": "参照：" + }, + { + "indent": 12, + "text": "this document", + "ja": "このドキュメント" + }, + { + "indent": 0, + "text": "7.5.2. addressBookIds", + "section_title": true, + "ja": "7.5.2. addressbookids" + }, + { + "indent": 3, + "text": "Property Name:", + "ja": "プロパティ名：" + }, + { + "indent": 12, + "text": "addressBookIds", + "ja": "addressbookids" + }, + { + "indent": 3, + "text": "Property Type:", + "ja": "プロパティタイプ：" + }, + { + "indent": 12, + "text": "not applicable", + "ja": "適用できない" + }, + { + "indent": 3, + "text": "Property Context:", + "ja": "プロパティコンテキスト：" + }, + { + "indent": 12, + "text": "Card", + "ja": "カード" + }, + { + "indent": 3, + "text": "Intended Usage:", + "ja": "意図された使用法：" + }, + { + "indent": 12, + "text": "reserved", + "ja": "予約済み" + }, + { + "indent": 3, + "text": "Since Version:", + "ja": "バージョン以来：" + }, + { + "indent": 12, + "text": "1.0", + "ja": "1.0" + }, + { + "indent": 3, + "text": "Change Controller:", + "ja": "Change Controller：" + }, + { + "indent": 12, + "text": "IETF", + "ja": "IETF" + }, + { + "indent": 3, + "text": "Reference:", + "ja": "参照：" + }, + { + "indent": 12, + "text": "this document", + "ja": "このドキュメント" + }, + { + "indent": 0, + "text": "7.5.3. blobId", + "section_title": true, + "ja": "7.5.3. ブロビッド" + }, + { + "indent": 3, + "text": "Property Name:", + "ja": "プロパティ名：" + }, + { + "indent": 12, + "text": "blobId", + "ja": "ブロビッド" + }, + { + "indent": 3, + "text": "Property Type:", + "ja": "プロパティタイプ：" + }, + { + "indent": 12, + "text": "not applicable", + "ja": "適用できない" + }, + { + "indent": 3, + "text": "Property Context:", + "ja": "プロパティコンテキスト：" + }, + { + "indent": 12, + "text": "Media", + "ja": "メディア" + }, + { + "indent": 3, + "text": "Intended Usage:", + "ja": "意図された使用法：" + }, + { + "indent": 12, + "text": "reserved", + "ja": "予約済み" + }, + { + "indent": 3, + "text": "Since Version:", + "ja": "バージョン以来：" + }, + { + "indent": 12, + "text": "1.0", + "ja": "1.0" + }, + { + "indent": 3, + "text": "Change Controller:", + "ja": "Change Controller：" + }, + { + "indent": 12, + "text": "IETF", + "ja": "IETF" + }, + { + "indent": 3, + "text": "Reference:", + "ja": "参照：" + }, + { + "indent": 12, + "text": "this document", + "ja": "このドキュメント" + }, + { + "indent": 0, + "text": "8. References", + "section_title": true, + "ja": "8. 参考文献" + }, + { + "indent": 0, + "text": "8.1. Normative References", + "section_title": true, + "ja": "8.1. 引用文献" + }, + { + "indent": 3, + "text": "[RFC2119] Bradner, S., \"Key words for use in RFCs to Indicate\n Requirement Levels\", BCP 14, RFC 2119,\n DOI 10.17487/RFC2119, March 1997,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC2397] Masinter, L., \"The \"data\" URL scheme\", RFC 2397,\n DOI 10.17487/RFC2397, August 1998,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8174] Leiba, B., \"Ambiguity of Uppercase vs Lowercase in RFC\n 2119 Key Words\", BCP 14, RFC 8174, DOI 10.17487/RFC8174,\n May 2017, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8620] Jenkins, N. and C. Newman, \"The JSON Meta Application\n Protocol (JMAP)\", RFC 8620, DOI 10.17487/RFC8620, July\n 2019, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC9553] Stepanek, R. and M. Loffredo, \"JSContact: A JSON\n Representation of Contact Data\", RFC 9553,\n DOI 10.17487/RFC9553, May 2024,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC9670] Jenkins, N., Ed., \"JSON Meta Application Protocol (JMAP)\n Sharing\", RFC 9670, DOI 10.17487/RFC9670, November 2024,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "8.2. Informative References", + "section_title": true, + "ja": "8.2. 参考引用" + }, + { + "indent": 3, + "text": "[RFC8264] Saint-Andre, P. and M. Blanchet, \"PRECIS Framework:\n Preparation, Enforcement, and Comparison of\n Internationalized Strings in Application Protocols\",\n RFC 8264, DOI 10.17487/RFC8264, October 2017,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[UNICODE] The Unicode Consortium, \"The Unicode Standard\",\n .", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "Author's Address", + "section_title": true, + "ja": "著者の連絡先" + }, + { + "indent": 3, + "text": "Neil Jenkins (editor)\nFastmail\nPO Box 234, Collins St West\nMelbourne VIC 8007\nAustralia\nEmail: neilj@fastmailteam.com\nURI: https://www.fastmail.com", + "raw": true, + "ja": "" + } + ] +} \ No newline at end of file diff --git a/data/9000/rfc9639-trans.json b/data/9000/rfc9639-trans.json new file mode 100644 index 000000000..b3b5d19c7 --- /dev/null +++ b/data/9000/rfc9639-trans.json @@ -0,0 +1,3319 @@ +{ + "title": { + "text": "RFC 9639 - Free Lossless Audio Codec (FLAC)", + "ja": "RFC 9639 - 無料のロスレスオーディオコーデック（FLAC）" + }, + "number": 9639, + "created_at": "2024-12-20 23:24:07.453540+09:00", + "updated_by": "", + "contents": [ + { + "indent": 0, + "text": "Internet Engineering Task Force (IETF) M.Q.C. van Beurden\nRequest for Comments: 9639 \nCategory: Standards Track A. Weaver\nISSN: 2070-1721 December 2024", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "Free Lossless Audio Codec (FLAC)", + "section_title": true, + "ja": "無料のロスレスオーディオコーデック（FLAC）" + }, + { + "indent": 0, + "text": "Abstract", + "section_title": true, + "ja": "概要" + }, + { + "indent": 3, + "text": "This document defines the Free Lossless Audio Codec (FLAC) format and its streamable subset. FLAC is designed to reduce the amount of computer storage space needed to store digital audio signals. It does this losslessly, i.e., it does so without losing information. FLAC is free in the sense that its specification is open and its reference implementation is open source. Compared to other lossless audio coding formats, FLAC is a format with low complexity and can be encoded and decoded with little computing resources. Decoding of FLAC has been implemented independently for many different platforms, and both encoding and decoding can be implemented without needing floating-point arithmetic.", + "ja": "このドキュメントでは、無料のロスレスオーディオコーデック（FLAC）形式とそのストリーミング可能なサブセットを定義します。FLACは、デジタルオーディオ信号の保存に必要なコンピューターストレージスペースの量を減らすように設計されています。これは損失がなく、つまり、情報を失うことなくそうします。FLACは、その仕様が開かれており、参照実装がオープンソースであるという意味で無料です。他のロスレスオーディオコーディング形式と比較して、FLACは複雑さが低い形式であり、コンピューティングリソースがほとんどないエンコードおよびデコードできます。FLACのデコードは、多くの異なるプラットフォームに対して独立して実装されており、フローティングポイント算術を必要とせずにエンコードとデコードの両方を実装できます。" + }, + { + "indent": 0, + "text": "Status of This Memo", + "section_title": true, + "ja": "本文書の位置付け" + }, + { + "indent": 3, + "text": "This is an Internet Standards Track document.", + "ja": "これは、インターネット標準トラックドキュメントです。" + }, + { + "indent": 3, + "text": "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.", + "ja": "このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。" + }, + { + "indent": 3, + "text": "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/rfc9639.", + "ja": "このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9639で取得できます。" + }, + { + "indent": 0, + "text": "Copyright Notice", + "section_title": true, + "ja": "著作権表示" + }, + { + "indent": 3, + "text": "Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.", + "ja": "著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。" + }, + { + "indent": 3, + "text": "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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.", + "ja": "このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。" + }, + { + "indent": 0, + "text": "Table of Contents", + "section_title": true, + "ja": "目次" + }, + { + "indent": 3, + "text": "1. Introduction\n2. Notation and Conventions\n3. Definitions\n4. Conceptual Overview\n 4.1. Blocking\n 4.2. Interchannel Decorrelation\n 4.3. Prediction\n 4.4. Residual Coding\n5. Format Principles\n6. Format Layout Overview\n7. Streamable Subset\n8. File-Level Metadata\n 8.1. Metadata Block Header\n 8.2. Streaminfo\n 8.3. Padding\n 8.4. Application\n 8.5. Seek Table\n 8.5.1. Seek Point\n 8.6. Vorbis Comment\n 8.6.1. Standard Field Names\n 8.6.2. Channel Mask\n 8.7. Cuesheet\n 8.7.1. Cuesheet Track\n 8.8. Picture\n9. Frame Structure\n 9.1. Frame Header\n 9.1.1. Block Size Bits\n 9.1.2. Sample Rate Bits\n 9.1.3. Channels Bits\n 9.1.4. Bit Depth Bits\n 9.1.5. Coded Number\n 9.1.6. Uncommon Block Size\n 9.1.7. Uncommon Sample Rate\n 9.1.8. Frame Header CRC\n 9.2. Subframes\n 9.2.1. Subframe Header\n 9.2.2. Wasted Bits per Sample\n 9.2.3. Constant Subframe\n 9.2.4. Verbatim Subframe\n 9.2.5. Fixed Predictor Subframe\n 9.2.6. Linear Predictor Subframe\n 9.2.7. Coded Residual\n 9.3. Frame Footer\n10. Container Mappings\n 10.1. Ogg Mapping\n 10.2. Matroska Mapping\n 10.3. ISO Base Media File Format (MP4) Mapping\n11. Security Considerations\n12. IANA Considerations\n 12.1. Media Type Registration\n 12.2. FLAC Application Metadata Block IDs Registry\n13. References\n 13.1. Normative References\n 13.2. Informative References\nAppendix A. Numerical Considerations\n A.1. Determining the Necessary Data Type Size\n A.2. Stereo Decorrelation\n A.3. Prediction\n A.4. Residual\n A.5. Rice Coding\nAppendix B. Past Format Changes\n B.1. Addition of Blocking Strategy Bit\n B.2. Restriction of Encoded Residual Samples\n B.3. Addition of 5-Bit Rice Parameters\n B.4. Restriction of LPC Shift to Non-negative Values\nAppendix C. Interoperability Considerations\n C.1. Features outside of the Streamable Subset\n C.2. Variable Block Size\n C.3. 5-Bit Rice Parameters\n C.4. Rice Escape Code\n C.5. Uncommon Block Size\n C.6. Uncommon Bit Depth\n C.7. Multi-Channel Audio and Uncommon Sample Rates\n C.8. Changing Audio Properties Mid-Stream\nAppendix D. Examples\n D.1. Decoding Example 1\n D.1.1. Example File 1 in Hexadecimal Representation\n D.1.2. Example File 1 in Binary Representation\n D.1.3. Signature and Streaminfo\n D.1.4. Audio Frames\n D.2. Decoding Example 2\n D.2.1. Example File 2 in Hexadecimal Representation\n D.2.2. Example File 2 in Binary Representation (Only Audio\n Frames)\n D.2.3. Streaminfo Metadata Block\n D.2.4. Seek Table\n D.2.5. Vorbis Comment\n D.2.6. Padding\n D.2.7. First Audio Frame\n D.2.8. Second Audio Frame\n D.2.9. MD5 Checksum Verification\n D.3. Decoding Example 3\n D.3.1. Example File 3 in Hexadecimal Representation\n D.3.2. Example File 3 in Binary Representation (Only Audio\n Frame)\n D.3.3. Streaminfo Metadata Block\n D.3.4. Audio Frame\nAcknowledgments\nAuthors' Addresses", + "raw": true, + "toc": true, + "ja": "" + }, + { + "indent": 0, + "text": "1. Introduction", + "section_title": true, + "ja": "1. はじめに" + }, + { + "indent": 3, + "text": "This document defines the Free Lossless Audio Codec (FLAC) format and its streamable subset. FLAC files and streams can code for pulse-code modulated (PCM) audio with 1 to 8 channels, sample rates from 1 to 1048575 hertz, and bit depths from 4 to 32 bits. Most tools for coding to and decoding from the FLAC format have been optimized for CD-audio, which is PCM audio with 2 channels, a sample rate of 44.1 kHz, and a bit depth of 16 bits.", + "ja": "このドキュメントでは、無料のロスレスオーディオコーデック（FLAC）形式とそのストリーミング可能なサブセットを定義します。FLACファイルとストリームは、1〜8チャンネル、1〜1048575 Hertz、および4〜32ビットのビット深度を備えたパルスコード変調（PCM）オーディオをコーディングできます。FLAC形式のコーディングとデコードのためのほとんどのツールは、2つのチャネル、44.1 kHzのサンプルレート、および16ビットの少し深さを備えたPCMオーディオであるCD-Audio向けに最適化されています。" + }, + { + "indent": 3, + "text": "FLAC is able to achieve lossless compression because samples in audio signals tend to be highly correlated with their close neighbors. In contrast with general-purpose compressors, which often use dictionaries, do run-length coding, or exploit long-term repetition, FLAC removes redundancy solely in the very short term, looking back at 32 samples at most.", + "ja": "FLACは、オーディオ信号のサンプルが近隣の隣人と高度に相関する傾向があるため、ロスレス圧縮を実現できます。しばしば辞書を使用したり、走行長のコーディングをしたり、長期的な繰り返しを活用したりする汎用コンプレッサーとは対照的に、FLACは非常に短期的にのみ冗長性を除去し、せいぜい32のサンプルを振り返ります。" + }, + { + "indent": 3, + "text": "The coding methods provided by the FLAC format work best on PCM audio signals with samples that have a signed representation and are centered around zero. Audio signals in which samples have an unsigned representation must be transformed to a signed representation as described in this document in order to achieve reasonable compression. The FLAC format is not suited for compressing audio that is not PCM.", + "ja": "FLAC形式によって提供されるコーディング方法は、署名された表現があり、ゼロを中心とするサンプルを使用して、PCMオーディオ信号で最適に機能します。合理的な圧縮を実現するために、このドキュメントで説明されているように、サンプルが署名されていない表現を持つオーディオ信号を署名した表現に変換する必要があります。FLAC形式は、PCMではないオーディオを圧縮するのに適していません。" + }, + { + "indent": 0, + "text": "2. Notation and Conventions", + "section_title": true, + "ja": "2. 表記と慣習" + }, + { + "indent": 3, + "text": "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.", + "ja": "「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 \"not\"、 \"becommended\"、 \"becommented\"、 \"may\"、 \"optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。" + }, + { + "indent": 3, + "text": "Values expressed as u(n) represent an unsigned big-endian integer using n bits. Values expressed as s(n) represent a signed big-endian integer using n bits, signed two's complement. Where necessary, n is expressed as an equation using * (multiplication), / (division), + (addition), or - (subtraction). An inclusive range of the number of bits expressed is represented with an ellipsis, such as u(m...n).", + "ja": "u（n）として表される値は、nビットを使用して署名されていないビッグエンディアン整数を表します。s（n）として表される値は、nビットを使用して署名されたビッグエンディアンの整数を表し、署名された2の補数を表します。必要に応じて、nは *（乗算）、 /（分割）、 +（追加）、または - （減算）を使用した方程式として表されます。発現するビット数の包括的な範囲は、u（m ... n）などの楕円で表されます。" + }, + { + "indent": 3, + "text": "All shifts mentioned in this document are arithmetic shifts.", + "ja": "このドキュメントに記載されているすべてのシフトは、算術シフトです。" + }, + { + "indent": 3, + "text": "While the FLAC format can store digital audio as well as other digital signals, this document uses terminology specific to digital audio. The use of more generic terminology was deemed less clear, so a reader interested in non-audio use of the FLAC format is expected to make the translation from audio-specific terms to more generic terminology.", + "ja": "FLAC形式はデジタルオーディオと他のデジタル信号を保存できますが、このドキュメントではデジタルオーディオに固有の用語を使用します。より一般的な用語の使用はそれほど明確ではないと見なされたため、FLAC形式の非オーディオ使用に関心のある読者は、オーディオ固有の用語からより一般的な用語への翻訳を行うことが期待されています。" + }, + { + "indent": 0, + "text": "3. Definitions", + "section_title": true, + "ja": "3. 定義" + }, + { + "indent": 3, + "text": "*Lossless compression*:", + "ja": "*ロスレス圧縮*：" + }, + { + "indent": 12, + "text": "Reducing the amount of computer storage space needed to store data without needing to remove or irreversibly alter any of this data in doing so. In other words, decompressing losslessly compressed information returns exactly the original data.", + "ja": "このデータを削除または不可逆的に変更する必要なく、データを保存するために必要なコンピューターストレージスペースの量を減らす。言い換えれば、損失のない圧縮情報を減圧すると、元のデータが正確に返されます。" + }, + { + "indent": 3, + "text": "*Lossy compression*:", + "ja": "*損失のある圧縮*：" + }, + { + "indent": 12, + "text": "Like lossless compression, but instead removing, irreversibly altering, or only approximating information for the purpose of further reducing the amount of computer storage space needed. In other words, decompressing lossy compressed information returns an approximation of the original data.", + "ja": "ロスレス圧縮のように、代わりに、必要なコンピューターストレージスペースの量をさらに削減する目的で、情報を削除、不可逆的に変更、または近似のみに近似します。言い換えれば、損失のある圧縮情報を減圧すると、元のデータの近似が返されます。" + }, + { + "indent": 3, + "text": "*Block*:", + "ja": "*ブロック*：" + }, + { + "indent": 12, + "text": "A (short) section of linear PCM audio with one or more channels.", + "ja": "1つ以上のチャネルを備えた線形PCMオーディオの（短い）セクション。" + }, + { + "indent": 3, + "text": "*Subblock*:", + "ja": "*サブブロック*：" + }, + { + "indent": 12, + "text": "All samples within a corresponding block for one channel. One or more subblocks form a block, and all subblocks in a certain block contain the same number of samples.", + "ja": "1つのチャネルの対応するブロック内のすべてのサンプル。1つ以上のサブブロックがブロックを形成し、特定のブロック内のすべてのサブブロックには同じ数のサンプルが含まれています。" + }, + { + "indent": 3, + "text": "*Frame*:", + "ja": "*フレーム*：" + }, + { + "indent": 12, + "text": "A frame header, one or more subframes, and a frame footer. It encodes the contents of a corresponding block.", + "ja": "フレームヘッダー、1つ以上のサブフレーム、およびフレームフッター。対応するブロックの内容をコードします。" + }, + { + "indent": 3, + "text": "*Subframe*:", + "ja": "*サブフレーム*：" + }, + { + "indent": 12, + "text": "An encoded subblock. All subframes within a frame code for the same number of samples. When interchannel decorrelation is used, a subframe can correspond to either the (per-sample) average of two subblocks or the (per-sample) difference between two subblocks, instead of to a subblock directly; see Section 4.2.", + "ja": "エンコードされたサブブロック。同じ数のサンプルのフレームコード内のすべてのサブフレーム。インターチャネルの切り相関を使用すると、サブフレームは、サブブロックの2つのサブブロックの（サンプルごとの）平均（サンプルごと）の差に直接対応できます。セクション4.2を参照してください。" + }, + { + "indent": 3, + "text": "*Interchannel samples*:", + "ja": "*インターチャネルサンプル*：" + }, + { + "indent": 12, + "text": "A sample count that applies to all channels. For example, one second of 44.1 kHz audio has 44100 interchannel samples, meaning each channel has that number of samples.", + "ja": "すべてのチャネルに適用されるサンプルカウント。たとえば、44.1 KHzオーディオの1秒には44100個のチャネルインターチャネルサンプルがあります。つまり、各チャネルにはその数のサンプルがあります。" + }, + { + "indent": 3, + "text": "*Block size*:", + "ja": "*ブロックサイズ*：" + }, + { + "indent": 12, + "text": "The number of interchannel samples contained in a block or coded in a frame.", + "ja": "ブロックに含まれるか、フレームにコード化されたインターチャネルサンプルの数。" + }, + { + "indent": 3, + "text": "*Bit depth* or *bits per sample*:", + "ja": "*サンプルごとにビット深さ*または*ビット*：" + }, + { + "indent": 12, + "text": "The number of bits used to contain each sample. This MUST be the same for all subblocks in a block but MAY be different for different subframes in a frame because of interchannel decorrelation. (See Section 4.2 for details on interchannel decorrelation.)", + "ja": "各サンプルを含むために使用されるビット数。これは、ブロック内のすべてのサブブロックで同じである必要がありますが、チャネル間の切り相関があるため、フレーム内の異なるサブフレームで異なる場合があります。（インターチャンネルの切り相関の詳細については、セクション4.2を参照してください。）" + }, + { + "indent": 3, + "text": "*Predictor*:", + "ja": "*予測因子*：" + }, + { + "indent": 12, + "text": "A model used to predict samples in an audio signal based on past samples. FLAC uses such predictors to remove redundancy in a signal in order to be able to compress it.", + "ja": "過去のサンプルに基づいてオーディオ信号のサンプルを予測するために使用されるモデル。FLACは、このような予測因子を使用して、信号の冗長性を削除して圧縮できるようにします。" + }, + { + "indent": 3, + "text": "*Linear predictor*:", + "ja": "*線形予測因子*：" + }, + { + "indent": 12, + "text": "A predictor using linear prediction (see [LinearPrediction]). This is also called *linear predictive coding (LPC)*. With a linear predictor, each prediction is a linear combination of past samples (hence the name). A linear predictor has a causal discrete-time finite impulse response (see [FIR]).", + "ja": "線形予測を使用した予測因子（[線形予測]を参照）。これは、 *線形予測コーディング（LPC） *とも呼ばれます。線形予測因子を使用すると、各予測は過去のサンプルの線形結合です（したがって名前）。線形予測因子には、因果的な離散時間有限インパルス応答があります（[FIR]を参照）。" + }, + { + "indent": 3, + "text": "*Fixed predictor*:", + "ja": "*予測因子を修正*：" + }, + { + "indent": 12, + "text": "A linear predictor in which the model parameters are the same across all FLAC files and thus do not need to be stored.", + "ja": "モデルパラメーターがすべてのFLACファイルで同じであるため、保存する必要はない線形予測因子。" + }, + { + "indent": 3, + "text": "*Predictor order*:", + "ja": "*予測因子順序*：" + }, + { + "indent": 12, + "text": "The number of past samples that a predictor uses. For example, a 4th order predictor uses the 4 samples directly preceding a certain sample to predict it. In FLAC, samples used in a predictor are always consecutive and are always the samples directly before the sample that is being predicted.", + "ja": "予測子が使用する過去のサンプルの数。たとえば、4次予測子は、特定のサンプルの直前の4つのサンプルを使用して予測します。FLACでは、予測子で使用されるサンプルは常に連続しており、常に予測されているサンプルの直前のサンプルです。" + }, + { + "indent": 3, + "text": "*Residual*:", + "ja": "*残差*：" + }, + { + "indent": 12, + "text": "The audio signal that remains after a predictor has been subtracted from a subblock. If the predictor has been able to remove redundancy from the signal, the samples of the remaining signal (the *residual samples*) will have, on average, a numerical value closer to zero than the original signal.", + "ja": "予測子がサブブロックから差し引かれた後に残るオーディオ信号。予測子が信号から冗長性を削除できた場合、残りの信号（ *残差サンプル *）のサンプルには、平均して、元の信号よりもゼロに近い数値があります。" + }, + { + "indent": 3, + "text": "*Rice code*:", + "ja": "*稲法*：" + }, + { + "indent": 12, + "text": "A variable-length code (see [VarLengthCode]). It uses a short code for samples close to zero and a progressively longer code for samples further away from zero. This makes use of the observation that residual samples are often close to zero.", + "ja": "変数長コード（[varlengthcode]を参照）。ゼロに近いサンプルには短いコードを使用し、ゼロから遠く離れたサンプルに次第に長いコードを使用します。これにより、残留サンプルはしばしばゼロに近いという観察が利用されます。" + }, + { + "indent": 3, + "text": "*Muxing*:", + "ja": "*マクシング*：" + }, + { + "indent": 12, + "text": "Short for multiplexing. Combining several streams or files into a single stream or file. In the context of this document, muxing specifically refers to embedding a FLAC stream in a container as described in Section 10.", + "ja": "多重化の略。いくつかのストリームまたはファイルを単一のストリームまたはファイルに結合します。このドキュメントのコンテキストでは、Muxingは、セクション10で説明されているように、コンテナにFLACストリームを埋め込むことを特に指します。" + }, + { + "indent": 0, + "text": "4. Conceptual Overview", + "section_title": true, + "ja": "4. 概念的概要" + }, + { + "indent": 3, + "text": "Similar to many other audio coders, a FLAC file is encoded following the steps below. To decode a FLAC file, these steps are performed in reverse order, i.e., from bottom to top.", + "ja": "他の多くのオーディオコーダーと同様に、FLACファイルは以下の手順に従ってエンコードされています。FLACファイルをデコードするには、これらの手順は逆の順序で、つまり下から上に実行されます。" + }, + { + "indent": 8, + "text": "1. *Blocking* (see Section 4.1). The input is split up into many contiguous blocks.", + "ja": "1. *ブロック*（セクション4.1を参照）。入力は、多くの連続したブロックに分割されます。" + }, + { + "indent": 8, + "text": "2. *Interchannel Decorrelation* (see Section 4.2). In the case of stereo streams, the FLAC format allows for transforming the left-right signal into a mid-side signal, a left-side signal, or a side-right signal to remove redundancy between channels. Choosing between any of these transformations is done independently for each block.", + "ja": "2. *交換相関関係*（セクション4.2を参照）。ステレオストリームの場合、FLAC形式では、左右信号をミッドサイド信号、左側信号、またはチャネル間の冗長性を除去する側面右信号に変換できます。これらの変換のいずれかを選択することは、各ブロックに対して個別に行われます。" + }, + { + "indent": 8, + "text": "3. *Prediction* (see Section 4.3). To remove redundancy in a signal, a predictor is stored for each subblock or its transformation as formed in the previous step. A predictor consists of a simple mathematical description that can be used, as the name implies, to predict a certain sample from the samples that preceded it. As this prediction is rarely exact, the error of this prediction is passed on to the next stage. The predictor of each subblock is completely independent from other subblocks. Since the methods of prediction are known to both the encoder and decoder, only the parameters of the predictor need to be included in the compressed stream. If no usable predictor can be found for a certain subblock, the signal is stored uncompressed, and the next stage is skipped.", + "ja": "3. *予測*（セクション4.3を参照）。信号の冗長性を削除するために、前のステップで形成された各サブブロックまたはその変換に対して予測子が保存されます。予測因子は、名前が示すように、それに先行するサンプルから特定のサンプルを予測するために使用できる単純な数学的説明で構成されています。この予測はめったに正確ではないため、この予測の誤差は次の段階に渡されます。各サブブロックの予測因子は、他のサブブロックから完全に独立しています。予測の方法はエンコーダーとデコーダーの両方に知られているため、予測子のパラメーターのみを圧縮ストリームに含める必要があります。特定のサブブロックに対して使用可能な予測子が見つからない場合、信号は圧縮されていない保存され、次の段階がスキップされます。" + }, + { + "indent": 8, + "text": "4. *Residual Coding* (see Section 4.4). As the predictor does not describe the signal exactly, the difference between the original signal and the predicted signal (called the error or residual signal) is coded losslessly. If the predictor is effective, the residual signal will require fewer bits per sample than the original signal. FLAC uses Rice coding, a subset of Golomb coding, with either 4-bit or 5-bit parameters to code the residual signal.", + "ja": "4. *残留コーディング*（セクション4.4を参照）。予測子は信号を正確に記述していないため、元の信号と予測信号（エラーまたは残差信号と呼ばれる）の違いは損失を及ぼさないほどコード化されます。予測子が有効な場合、残差信号は元の信号よりもサンプルあたりのビットが少なくなります。FLACは、残差信号をコーディングするために、4ビットまたは5ビットパラメーターを備えたGolombコーディングのサブセットであるRice Codingを使用します。" + }, + { + "indent": 3, + "text": "In addition, FLAC specifies a metadata system (see Section 8) that allows arbitrary information about the stream to be included at the beginning of the stream.", + "ja": "さらに、FLACは、ストリームの開始時にストリームに関する任意の情報を含めるメタデータシステム（セクション8を参照）を指定します。" + }, + { + "indent": 0, + "text": "4.1. Blocking", + "section_title": true, + "ja": "4.1. ブロッキング" + }, + { + "indent": 3, + "text": "The block size used for audio data has a direct effect on the compression ratio. If the block size is too small, the resulting large number of frames means that a disproportionate number of bytes will be spent on frame headers. If the block size is too large, the characteristics of the signal may vary so much that the encoder will be unable to find a good predictor. In order to simplify encoder/ decoder design, FLAC imposes a minimum block size of 16 samples, except for the last block, and a maximum block size of 65535 samples. The last block is allowed to be smaller than 16 samples to be able to match the length of the encoded audio without using padding.", + "ja": "オーディオデータに使用されるブロックサイズは、圧縮比に直接的な影響を及ぼします。ブロックサイズが小さすぎる場合、結果として生じる多くのフレームは、フレームヘッダーに不均衡な数のバイト数が使用されることを意味します。ブロックサイズが大きすぎると、信号の特性が大きく異なる場合があるため、エンコーダーは適切な予測因子を見つけることができません。エンコーダー/デコーダー設計を簡素化するために、FLACは、最後のブロックを除き、16のサンプルの最小ブロックサイズと65535サンプルの最大ブロックサイズを課します。最後のブロックは、パディングを使用せずにエンコードされたオーディオの長さを一致させるために、16枚未満のサンプルになります。" + }, + { + "indent": 3, + "text": "While the block size does not have to be constant in a FLAC file, it is often difficult to find the optimal arrangement of block sizes for maximum compression. Because of this, a FLAC stream has explicitly either a constant or variable block size throughout and stores a block number instead of a sample number to slightly improve compression if a stream has a constant block size.", + "ja": "ブロックサイズはFLACファイルで一定である必要はありませんが、最大圧縮のためにブロックサイズの最適な配置を見つけることはしばしば困難です。このため、FLACストリームは、全体に一定または可変ブロックサイズを明示的に備えており、サンプル番号の代わりにブロック番号を保存して、ストリームに一定のブロックサイズがある場合は圧縮をわずかに改善します。" + }, + { + "indent": 0, + "text": "4.2. Interchannel Decorrelation", + "section_title": true, + "ja": "4.2. チャンネル間の切り相関" + }, + { + "indent": 3, + "text": "Channels are correlated in many audio files. The FLAC format can exploit this correlation in stereo files by coding an average of all samples in both subblocks (a mid channel) or the difference between all samples in both subblocks (a side channel) instead of directly coding subblocks into subframes. The following combinations are possible:", + "ja": "チャネルは多くのオーディオファイルで相関しています。FLAC形式は、サブブロックをサブフレームに直接コーディングする代わりに、両方のサブブロック（ミッドチャネル）のすべてのサンプルの平均または両方のサブブロック（サイドチャネル）のすべてのサブブロックの平均をコーディングすることにより、ステレオファイルのこの相関を活用できます。次の組み合わせが可能です。" + }, + { + "indent": 6, + "text": "* *Independent*. All channels are coded independently. All non-stereo files MUST be encoded this way.", + "ja": "* *独立した*。すべてのチャネルは独立してコーディングされます。すべての非ステレオファイルはこの方法でエンコードする必要があります。" + }, + { + "indent": 6, + "text": "* *Mid-side*. A left and right subblock are converted to mid and side subframes. To calculate a sample for a mid subframe, the corresponding left and right samples are summed, and the result is shifted right by 1 bit. To calculate a sample for a side subframe, the corresponding right sample is subtracted from the corresponding left sample. On decoding, all mid channel samples have to be shifted left by 1 bit. Also, if a side channel sample is odd, 1 has to be added to the corresponding mid channel sample after it has been shifted left by 1 bit. To reconstruct the left channel, the corresponding samples in the mid and side subframes are added and the result shifted right by 1 bit. For the right channel, the side channel has to be subtracted from the mid channel and the result shifted right by 1 bit.", + "ja": "* *ミッドサイド*。左右のサブブロックは、ミッドサブフレームとサイドサブフレームに変換されます。ミッドサブフレームのサンプルを計算するために、対応する左右のサンプルが合計され、結果は1ビットずつシフトします。サイドサブフレームのサンプルを計算するには、対応する右サンプルが対応する左サンプルから差し引かれます。デコードでは、すべてのミッドチャネルサンプルを1ビット左にシフトする必要があります。また、サイドチャネルサンプルが奇数の場合、1ビットの残りをシフトした後、対応するミッドチャネルサンプルに1を追加する必要があります。左チャネルを再構築するために、中央および側面のサブフレームの対応するサンプルが追加され、結果が1ビット右にシフトしました。右チャネルの場合、サイドチャネルをミッドチャネルから差し引く必要があり、結果は1ビット右にシフトしました。" + }, + { + "indent": 6, + "text": "* *Left-side*. The left subblock is coded, and the left and right subblocks are used to code a side subframe. The side subframe is constructed in the same way as for mid-side. To decode, the right subblock is restored by subtracting the samples in the side subframe from the corresponding samples in the left subframe.", + "ja": "* *左側*。左サブブロックがコード化されており、左右のサブブロックを使用してサイドサブフレームをコーディングします。サイドサブフレームは、ミッドサイドと同じ方法で構築されます。デコードするには、右サブブロックが左サブフレームの対応するサンプルからサイドサブフレームのサンプルを差し引くことで復元されます。" + }, + { + "indent": 6, + "text": "* *Side-right*. The left and right subblocks are used to code a side subframe, and the right subblock is coded. The side subframe is constructed in the same way as for mid-side. To decode, the left subblock is restored by adding the samples in the side subframe to the corresponding samples in the right subframe.", + "ja": "* *side-right*。左右のサブブロックは、サイドサブフレームのコーディングに使用され、右サブブロックがコーディングされています。サイドサブフレームは、ミッドサイドと同じ方法で構築されます。デコードするには、右サブフレームのサンプルを右サブフレームの対応するサンプルに追加することにより、左サブブロックが復元されます。" + }, + { + "indent": 3, + "text": "The side channel needs one extra bit of bit depth, as the subtraction can produce sample values twice as large as the maximum possible in any given bit depth. The mid channel in mid-side stereo does not need one extra bit, as it is shifted right 1 bit. The right shift of the mid channel does not lead to lossy behavior because an odd sample in the mid subframe must always be accompanied by a corresponding odd sample in the side subframe, which means the lost least-significant bit can be restored by taking it from the sample in the side subframe.", + "ja": "サイドチャネルには、減算が任意のビット深度で可能な最大値の2倍のサンプル値を生成できるため、ビットの深さを1つ追加する必要があります。ミッドサイドステレオのミッドチャネルは、1ビットにシフトされているため、追加のビットは必要ありません。ミッドチャネルの正しいシフトは、ミッドサブフレームの奇数サンプルには常にサイドサブフレームに対応する奇数サンプルを添付する必要があるため、損失のある動作につながりません。サイドサブフレームのサンプル。" + }, + { + "indent": 0, + "text": "4.3. Prediction", + "section_title": true, + "ja": "4.3. 予測" + }, + { + "indent": 3, + "text": "The FLAC format has four methods for modeling the input signal:", + "ja": "FLAC形式には、入力信号をモデル化する4つの方法があります。" + }, + { + "indent": 8, + "text": "1. *Verbatim*. Samples are stored directly, without any modeling. This method is used for inputs with little correlation. Since the raw signal is not actually passed through the residual coding stage (it is added to the stream \"verbatim\"), this method is different from using a zero-order fixed predictor.", + "ja": "1. *Verbatim*。サンプルは、モデリングなしで直接保存されます。この方法は、ほとんど相関関係がない入力に使用されます。生の信号は実際には残留コーディング段階を通過しないため（ストリーム「逐語」）、この方法はゼロオーダー固定予測子を使用することとは異なります。" + }, + { + "indent": 8, + "text": "2. *Constant*. A single sample value is stored. This method is used whenever a signal is pure DC (\"digital silence\"), i.e., a constant value throughout.", + "ja": "2. *絶え間ない*。単一のサンプル値が保存されます。この方法は、信号が純粋なDC（「デジタルサイレンス」）、つまり全体の一定の値である場合はいつでも使用されます。" + }, + { + "indent": 8, + "text": "3. *Fixed predictor*. Samples are predicted with one of five fixed (i.e., predefined) predictors, and the error of this prediction is processed by the residual coder. These fixed predictors are well suited for predicting simple waveforms. Since the predictors are fixed, no predictor coefficients are stored. From a mathematical point of view, the predictors work by extrapolating the signal from the previous samples. The number of previous samples used is equal to the predictor order. For more information, see Section 9.2.5.", + "ja": "3. *予測因子を修正*。サンプルは、5つの固定（つまり、事前定義された）予測因子のいずれかで予測され、この予測の誤差は残差コーダーによって処理されます。これらの固定予測因子は、単純な波形を予測するのに適しています。予測因子は固定されているため、予測係数は保存されません。数学的な観点から、予測因子は以前のサンプルから信号を外挿することにより機能します。以前のサンプルの数は、予測順に等しくなります。詳細については、セクション9.2.5を参照してください。" + }, + { + "indent": 8, + "text": "4. *Linear predictor*. Samples are predicted using past samples and a set of predictor coefficients, and the error of this prediction is processed by the residual coder. Compared to a fixed predictor, using a generic linear predictor adds overhead as predictor coefficients need to be stored. Therefore, this method of prediction is best suited for predicting more complex waveforms, where the added overhead is offset by space savings in the residual coding stage resulting from more accurate prediction. A linear predictor in FLAC has two parameters besides the predictor coefficients and the predictor order: the number of bits with which each coefficient is stored (the coefficient precision) and a prediction right shift. A prediction is formed by taking the sum of multiplying each predictor coefficient with the corresponding past sample and dividing that sum by applying the specified right shift. For more information, see Section 9.2.6.", + "ja": "4. *線形予測因子*。サンプルは、過去のサンプルと一連の予測係数を使用して予測され、この予測の誤差は残差コーダーによって処理されます。固定予測子と比較して、一般的な線形予測因子を使用すると、予測係数を保存する必要があるためオーバーヘッドが追加されます。したがって、この予測の方法は、より正確な予測に起因する残留コーディング段階でのスペースの節約により、より複雑な波形を予測するのに最適です。FLACの線形予測因子には、予測係数と予測因子の順序以外に2つのパラメーターがあります。各係数が保存されるビット数（係数精度）と予測の正しいシフトです。予測は、各予測子係数に対応する過去のサンプルを掛け、指定された右シフトを適用してその合計を分割することによって形成されます。詳細については、セクション9.2.6を参照してください。" + }, + { + "indent": 3, + "text": "A FLAC encoder is free to select any of the above methods to model the input. However, to ensure lossless coding, the following exceptions apply:", + "ja": "FLACエンコーダーは、入力をモデル化するための上記の方法のいずれかを自由に選択できます。ただし、ロスレスコーディングを確保するには、次の例外が適用されます。" + }, + { + "indent": 6, + "text": "* When the samples that need to be stored do not all have the same value (i.e., the signal is not constant), a constant subframe cannot be used.", + "ja": "* 保存する必要があるサンプルがすべて同じ値を持っているわけではない場合（つまり、信号は一定ではありません）、一定のサブフレームを使用できません。" + }, + { + "indent": 6, + "text": "* When an encoder is unable to find a fixed or linear predictor for which all residual samples are representable in 32-bit signed integers as stated in Section 9.2.7, a verbatim subframe is used.", + "ja": "* セクション9.2.7に記載されているように、すべての残差サンプルが32ビットの署名された整数で表される固定または線形予測因子をエンコーダが見つけることができない場合、逐語的なサブフレームが使用されます。" + }, + { + "indent": 3, + "text": "For more information on fixed and linear predictors, see [Lossless-Compression] and [Robinson-TR156].", + "ja": "固定および線形予測因子の詳細については、[ロブンソン-TR156]を参照してください。" + }, + { + "indent": 0, + "text": "4.4. Residual Coding", + "section_title": true, + "ja": "4.4. 残留コーディング" + }, + { + "indent": 3, + "text": "If a subframe uses a predictor to approximate the audio signal, a residual is stored to \"correct\" the approximation to the exact value. When an effective predictor is used, the average numerical value of the residual samples is smaller than that of the samples before prediction. While having smaller values on average, it is possible that a few \"outlier\" residual samples are much larger than any of the original samples. Sometimes these outliers even exceed the range that the bit depth of the original audio offers.", + "ja": "サブフレームが予測子を使用してオーディオ信号を近似する場合、残差は正確な値の近似を「修正」するように保存されます。効果的な予測因子を使用すると、残差サンプルの平均数値値は、予測前のサンプルの平均値よりも小さくなります。平均して値が小さい一方で、いくつかの「外れ値」残差サンプルが元のサンプルのいずれよりもはるかに大きい可能性があります。これらの外れ値は、元のオーディオのビット深度が提供する範囲を超えることがあります。" + }, + { + "indent": 3, + "text": "To efficiently code such a stream of relatively small numbers with an occasional outlier, Rice coding (a subset of Golomb coding) is used. Depending on how small the numbers are that have to be coded, a Rice parameter is chosen. The numerical value of each residual sample is split into two parts by dividing it by 2^(Rice parameter), creating a quotient and a remainder. The quotient is stored in unary form and the remainder in binary form. If indeed most residual samples are close to zero and a suitable Rice parameter is chosen, this form of coding, with a so-called variable-length code, uses fewer bits than the residual in unencoded form.", + "ja": "比較的少数のこのようなストリームを時折外れ値で効率的にコーディングするには、米コーディング（ゴロンコーディングのサブセット）が使用されます。コード化する必要がある数値がどれだけ少ないかに応じて、イネパラメーターが選択されます。各残差サンプルの数値は、2^（Riceパラメーター）で割ることにより、2つの部分に分割され、商と残りを作成します。商は単位形式で保存され、残りはバイナリ形式で保存されます。実際にほとんどの残留サンプルがゼロに近く、適切なイネパラメーターが選択されている場合、いわゆる可変長コードを使用したこの形式のコーディングは、エンコードされていない形の残差よりも少ないビットを使用します。" + }, + { + "indent": 3, + "text": "As Rice codes can only handle unsigned numbers, signed numbers are zigzag encoded to a so-called folded residual. See Section 9.2.7 for a more thorough explanation.", + "ja": "イネコードは署名されていない数値のみを処理できるため、署名された数値は、いわゆる折り畳まれた残留物にエンコードされたzigzagです。より徹底的な説明については、セクション9.2.7を参照してください。" + }, + { + "indent": 3, + "text": "Quite often, the optimal Rice parameter varies over the course of a subframe. To accommodate this, the residual can be split up into partitions, where each partition has its own Rice parameter. To keep overhead and complexity low, the number of partitions used in a subframe is limited to powers of two.", + "ja": "多くの場合、最適な米パラメーターはサブフレームの過程で変化します。これに対応するために、残差はパーティションに分割できます。各パーティションには独自のイネパラメーターがあります。オーバーヘッドと複雑さを低く保つために、サブフレームで使用されるパーティションの数は2つのパワーに限定されます。" + }, + { + "indent": 3, + "text": "The FLAC format uses two forms of Rice coding, which only differ in the number of bits used for encoding the Rice parameter, either 4 or 5 bits.", + "ja": "FLAC形式では、2つのフォームのイネコーディングを使用します。これは、4ビットまたは5ビットのライスパラメーターをエンコードするために使用されるビットの数のみが異なります。" + }, + { + "indent": 0, + "text": "5. Format Principles", + "section_title": true, + "ja": "5. 形式の原則" + }, + { + "indent": 3, + "text": "FLAC has no format version information, but it does contain reserved space in several places. Future versions of the format MAY use this reserved space safely without breaking the format of older streams. Older decoders MAY choose to abort decoding when encountering data that is encoded using methods they do not recognize. Apart from reserved patterns, the format specifies forbidden patterns in certain places, meaning that the patterns MUST NOT appear in any bitstream. They are listed in the following table.", + "ja": "FLACにはフォーマットバージョン情報はありませんが、いくつかの場所に予約スペースが含まれています。フォーマットの将来のバージョンは、古いストリームの形式を破ることなく、この予約スペースを安全に使用する場合があります。古いデコーダーは、認識されていないメソッドを使用してエンコードされたデータに遭遇する場合にデコードを中止することを選択できます。予約されたパターンとは別に、この形式は特定の場所で禁止されたパターンを指定します。つまり、パターンはどのビットストリームにも表示されてはなりません。次の表にリストされています。" + }, + { + "indent": 6, + "text": " +=========================================+=============+\n | Description | Reference |\n +=========================================+=============+\n | Metadata block type 127 | Section 8.1 |\n +-----------------------------------------+-------------+\n | Minimum and maximum block sizes smaller | Section 8.2 |\n | than 16 in streaminfo metadata block | |\n +-----------------------------------------+-------------+\n | Sample rate bits 0b1111 | Section |\n | | 9.1.2 |\n +-----------------------------------------+-------------+\n | Uncommon block size 65536 | Section |\n | | 9.1.6 |\n +-----------------------------------------+-------------+\n | Predictor coefficient precision bits | Section |\n | 0b1111 | 9.2.6 |\n +-----------------------------------------+-------------+\n | Negative predictor right shift | Section |\n | | 9.2.6 |\n +-----------------------------------------+-------------+\n\n Table 1", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "All numbers used in a FLAC bitstream are integers; there are no floating-point representations. All numbers are big-endian coded, except the field lengths used in Vorbis comments (see Section 8.6), which are little-endian coded. This exception for Vorbis comments is to keep as much commonality as possible with Vorbis comments as used by the Vorbis codec (see [Vorbis]). All numbers are unsigned except linear predictor coefficients, the linear prediction shift (see Section 9.2.6), and numbers that directly represent samples, which are signed. None of these restrictions apply to application metadata blocks or to Vorbis comment field contents.", + "ja": "FLACビットストリームで使用されるすべての数値は整数です。浮動小数点表現はありません。すべての数字は、Vorbisのコメントで使用されているフィールドの長さ（セクション8.6を参照）を除き、小さなエンディアンコード化されています。Vorbisコメントのこの例外は、Vorbis Codecで使用されているVorbisコメントと可能な限り多くの共通性を維持することです（[Vorbis]を参照）。すべての数値は、線形予測係数、線形予測シフト（セクション9.2.6を参照）、および署名されたサンプルを直接表す数値を除き、署名されていません。これらの制限はいずれも、アプリケーションメタデータブロックやVorbisコメントフィールドの内容には適用されません。" + }, + { + "indent": 3, + "text": "All samples encoded to and decoded from the FLAC format MUST be in a signed representation.", + "ja": "FLAC形式にエンコードされてデコードされたすべてのサンプルは、署名された表現である必要があります。" + }, + { + "indent": 3, + "text": "There are several ways to convert unsigned sample representations to signed sample representations, but the coding methods provided by the FLAC format work best on samples that have numerical values that are centered around zero, i.e., have no DC offset. In most unsigned audio formats, signals are centered around halfway within the range of the unsigned integer type used. If that is the case, converting sample representations by first copying the number to a signed integer with a sufficient range and then subtracting half of the range of the unsigned integer type results in a signal with samples centered around 0.", + "ja": "署名されていないサンプル表現を署名されたサンプル表現に変換する方法はいくつかありますが、FLAC形式によって提供されるコーディング方法は、ゼロを中心とする数値、つまりDCオフセットを持たないサンプルで最適に機能します。ほとんどの符号なしのオーディオ形式では、信号は使用されている署名されていない整数型の範囲内の中心にあります。その場合、最初に数字を十分な範囲の署名整数にコピーしてサンプル表現を変換し、次に署名されていない整数型の範囲の半分を減算すると、サンプルが0を中心となる信号が得られます。" + }, + { + "indent": 3, + "text": "Unary coding in a FLAC bitstream is done with zero bits terminated with a one bit, e.g., the number 5 is coded unary as 0b000001. This prevents the frame sync code from appearing in unary-coded numbers.", + "ja": "FLACビットストリームでの単位コーディングは、1ビットで終了したゼロビットで行われます。たとえば、ナンバー5は0B000001と統一されます。これにより、フレーム同期コードが単位コーディングされた数字で表示されないようにします。" + }, + { + "indent": 3, + "text": "When a FLAC file contains data that is forbidden or otherwise not valid, decoder behavior is left unspecified. A decoder MAY choose to stop decoding upon encountering such data. Examples of such data include the following:", + "ja": "FLACファイルに禁止されている、または無効なデータが含まれている場合、デコーダーの動作は不特定のままになります。デコーダーは、そのようなデータに遭遇したときにデコードを停止することを選択できます。そのようなデータの例には、以下が含まれます。" + }, + { + "indent": 6, + "text": "* One or more decoded sample values exceed the range offered by the bit depth as coded for that frame. For example, in a frame with a bit depth of 8 bits, any samples not in the inclusive range from -128 to 127 are not valid.", + "ja": "* 1つ以上のデコードされたサンプル値は、そのフレームにコード化されたビット深度によって提供される範囲を超えています。たとえば、8ビットの深さが少しあるフレームでは、-128〜127までの包括的な範囲にないサンプルは無効です。" + }, + { + "indent": 6, + "text": "* The number of wasted bits (see Section 9.2.2) used by a subframe is such that the bit depth of that subframe (see Section 9.2.3 for a description of subframe bit depth) equals zero or is negative.", + "ja": "* サブフレームで使用される無駄なビットの数（セクション9.2.2を参照）は、そのサブフレームのビット深さ（サブフレームビット深度の説明についてはセクション9.2.3を参照）がゼロに等しいか負のものです。" + }, + { + "indent": 6, + "text": "* A frame header Cyclic Redundancy Check (CRC) (see Section 9.1.8) or frame footer CRC (see Section 9.3) does not validate.", + "ja": "* フレームヘッダーサイクリック冗長チェック（CRC）（セクション9.1.8を参照）またはフレームフッターCRC（セクション9.3を参照）は検証しません。" + }, + { + "indent": 6, + "text": "* One of the forbidden bit patterns described in Table 1 is used.", + "ja": "* 表1で説明する禁じられたビットパターンの1つが使用されます。" + }, + { + "indent": 0, + "text": "6. Format Layout Overview", + "section_title": true, + "ja": "6. フォーマットレイアウトの概要" + }, + { + "indent": 3, + "text": "A FLAC bitstream consists of the fLaC (i.e., 0x664C6143) marker at the beginning of the stream, followed by a mandatory metadata block (called the streaminfo metadata block), any number of other metadata blocks, and then the audio frames.", + "ja": "FLACビットストリームは、ストリームの先頭にFLAC（つまり、0x664C6143）マーカーで構成され、その後、必須のメタデータブロック（Streaminfoメタデータブロックと呼ばれる）、他の任意の数のメタデータブロック、次にオーディオフレームが続きます。" + }, + { + "indent": 3, + "text": "FLAC supports 127 kinds of metadata blocks; currently, 7 kinds are defined in Section 8.", + "ja": "FLACは、127種類のメタデータブロックをサポートしています。現在、7種類はセクション8で定義されています。" + }, + { + "indent": 3, + "text": "The audio data is composed of one or more audio frames. Each frame consists of a frame header that contains a sync code, information about the frame (like the block size, sample rate, and number of channels), and an 8-bit CRC. The frame header also contains either the sample number of the first sample in the frame (for variable block size streams) or the frame number (for fixed block size streams). This allows for fast, sample-accurate seeking to be performed. Following the frame header are encoded subframes, one for each channel. The frame is then zero-padded to a byte boundary and finished with a frame footer containing a checksum for the frame. Each subframe has its own header that specifies how the subframe is encoded.", + "ja": "オーディオデータは、1つ以上のオーディオフレームで構成されています。各フレームは、同期コード、フレームに関する情報（ブロックサイズ、サンプルレート、チャネル数など）、および8ビットCRCを含むフレームヘッダーで構成されています。フレームヘッダーには、フレーム内の最初のサンプルのサンプル番号（可変ブロックサイズストリームの場合）またはフレーム番号（固定ブロックサイズストリームの場合）も含まれます。これにより、迅速でサンプルが順応性の高い探求が可能になります。フォローフレームヘッダーは、各チャネルに1つのエンコードされたサブフレームです。その後、フレームはバイト境界にゼロパッドされ、フレームのチェックサムを含むフレームフッターで仕上げられます。各サブフレームには、サブフレームのエンコード方法を指定する独自のヘッダーがあります。" + }, + { + "indent": 3, + "text": "In order to allow a decoder to start decoding at any place in the stream, each frame starts with a byte-aligned 15-bit sync code. However, since it is not guaranteed that the sync code does not appear elsewhere in the frame, the decoder can check that it synced correctly by parsing the rest of the frame header and validating the frame header CRC.", + "ja": "デコーダーがストリーム内の任意の場所でデコードを開始できるようにするために、各フレームはバイトに並べられた15ビット同期コードで始まります。ただし、同期コードがフレームの他の場所に表示されないことは保証されていないため、デコーダーはフレームヘッダーの残りの部分を解析し、フレームヘッダーCRCを検証することにより正しく同期していることを確認できます。" + }, + { + "indent": 3, + "text": "Furthermore, to allow a decoder to start decoding at any place in the stream even without having received a streaminfo metadata block, each frame header contains some basic information about the stream. This information includes sample rate, bits per sample, number of channels, etc. Since the frame header is overhead, it has a direct effect on the compression ratio. To keep the frame header as small as possible, FLAC uses lookup tables for the most commonly used values for frame properties. When a certain property has a value that is not covered by the lookup table, the decoder is directed to find the value of that property (for example, the sample rate) at the end of the frame header or in the streaminfo metadata block. If a frame header refers to the streaminfo metadata block, the file is not \"streamable\"; see Section 7 for details. By using lookup tables, the file is streamable and the frame header size is small for the most common forms of audio data.", + "ja": "さらに、Streaminfoメタデータブロックを受け取っていなくても、デコーダーがストリーム内の任意の場所でデコードを開始できるようにするために、各フレームヘッダーにはストリームに関する基本情報が含まれています。この情報には、サンプルレート、サンプルあたりのビット、チャネル数などが含まれます。フレームヘッダーは頭上であるため、圧縮率に直接的な影響があります。フレームヘッダーをできるだけ小さく保つために、FLACはフレームプロパティで最も一般的に使用される値にルックアップテーブルを使用します。特定のプロパティにルックアップテーブルでカバーされていない値がある場合、デコーダーは、フレームヘッダーの端またはstreaminfoメタデータブロックでそのプロパティの値（サンプルレートなど）を見つけるように指示されます。フレームヘッダーがStreaminfoメタデータブロックを指す場合、ファイルは「ストリーミング可能」ではありません。詳細については、セクション7を参照してください。ルックアップテーブルを使用することにより、ファイルはストリーミング可能であり、最も一般的なフォームのオーディオデータに対してフレームヘッダーサイズは小さくなります。" + }, + { + "indent": 3, + "text": "Individual subframes (one for each channel) are coded separately within a frame and appear serially in the stream. In other words, the encoded audio data is NOT channel-interleaved. This reduces decoder complexity at the cost of requiring larger decode buffers. Each subframe has its own header specifying the attributes of the subframe, like prediction method and order, residual coding parameters, etc. Each subframe header is followed by the encoded audio data for that channel.", + "ja": "個々のサブフレーム（各チャネルに1つ）は、フレーム内で個別にコーディングされ、ストリーム内に連続的に表示されます。言い換えれば、エンコードされたオーディオデータはチャネル介入ではありません。これにより、より大きなデコードバッファーを必要とするコストでデコーダーの複雑さが減少します。各サブフレームには、予測方法や順序、残留コーディングパラメーターなど、サブフレームの属性を指定する独自のヘッダーがあります。各サブフレームヘッダーの後に、そのチャネルのエンコードされたオーディオデータが続きます。" + }, + { + "indent": 0, + "text": "7. Streamable Subset", + "section_title": true, + "ja": "7. ストリーミング可能なサブセット" + }, + { + "indent": 3, + "text": "The FLAC format specifies a subset of itself as the FLAC streamable subset. The purpose of this is to ensure that any streams encoded according to this subset are truly \"streamable\", meaning that a decoder that cannot seek within the stream can still pick up in the middle of the stream and start decoding. It also makes hardware decoder implementations more practical by limiting the encoding parameters in such a way that decoder buffer sizes and other resource requirements can be easily determined. The streamable subset makes the following limitations on what MAY be used in the stream:", + "ja": "FLAC形式は、FLACストリーミング可能なサブセットとしてそれ自体のサブセットを指定します。これの目的は、このサブセットに従ってエンコードされたストリームが本当に「ストリーミング可能」であることを確認することです。つまり、ストリーム内で探すことができないデコーダーは、ストリームの中央でピックアップしてデコードを開始できることを意味します。また、デコーダーバッファーサイズやその他のリソース要件を簡単に決定できるように、エンコードパラメーターを制限することにより、ハードウェアデコーダーの実装をより実用的にします。ストリーム可能なサブセットは、ストリームで使用できるものに次の制限を作成します。" + }, + { + "indent": 6, + "text": "* The sample rate bits (see Section 9.1.2) in the frame header MUST be 0b0001-0b1110, i.e., the frame header MUST NOT refer to the streaminfo metadata block to describe the sample rate.", + "ja": "* フレームヘッダーのサンプルレートビット（セクション9.1.2を参照）は0B0001-0B1110でなければなりません。つまり、フレームヘッダーは、サンプルレートを記述するためにStreaminfoメタデータブロックを参照してはなりません。" + }, + { + "indent": 6, + "text": "* The bit depth bits (see Section 9.1.4) in the frame header MUST be 0b001-0b111, i.e., the frame header MUST NOT refer to the streaminfo metadata block to describe the bit depth.", + "ja": "* フレームヘッダーのビット深度ビット（セクション9.1.4を参照）は0B001-0B111でなければなりません。つまり、フレームヘッダーは、ビット深度を記述するためにStreaminfoメタデータブロックを参照してはなりません。" + }, + { + "indent": 6, + "text": "* The stream MUST NOT contain blocks with more than 16384 interchannel samples, i.e., the maximum block size must not be larger than 16384.", + "ja": "* ストリームには、16384を超えるチャンネルサンプルを持つブロックを含めてはなりません。つまり、最大ブロックサイズは16384を超えてはなりません。" + }, + { + "indent": 6, + "text": "* Audio with a sample rate less than or equal to 48000 Hz MUST NOT be contained in blocks with more than 4608 interchannel samples, i.e., the maximum block size used for this audio must not be larger than 4608.", + "ja": "* サンプルレートが48000 Hz以下のオーディオは、4608を超えるチャネルサンプルを備えたブロックに含める必要はありません。つまり、このオーディオに使用される最大ブロックサイズは4608を超えてはなりません。" + }, + { + "indent": 6, + "text": "* Linear prediction subframes (see Section 9.2.6) containing audio with a sample rate less than or equal to 48000 Hz MUST have a predictor order less than or equal to 12, i.e., the subframe type bits in the subframe header (see Section 9.2.1) MUST NOT be 0b101100-0b111111.", + "ja": "* 48000 Hz以下のサンプルレートを含むオーディオを含む線形予測サブフレーム（セクション9.2.6を参照）は、12以下の予測順、つまりサブフレームヘッダーのサブフレームタイプビット（セクション9.2を参照してください。1）0B101100-0B111111にしてはなりません。" + }, + { + "indent": 6, + "text": "* The Rice partition order (see Section 9.2.7) MUST be less than or equal to 8.", + "ja": "* イネの分配順序（セクション9.2.7を参照）は、8以下でなければなりません。" + }, + { + "indent": 6, + "text": "* The channel ordering MUST be equal to one defined in Section 9.1.3, i.e., the FLAC file MUST NOT need a WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag to describe the channel ordering. See Section 8.6.2 for details.", + "ja": "* チャネルの順序付けは、セクション9.1.3で定義されているものに等しくなければなりません。つまり、FLACファイルは、チャネルの順序付けを説明するために波形Xtensible_Channel_Maskタグを必要としないはずです。詳細については、セクション8.6.2を参照してください。" + }, + { + "indent": 0, + "text": "8. File-Level Metadata", + "section_title": true, + "ja": "8. ファイルレベルのメタデータ" + }, + { + "indent": 3, + "text": "At the start of a FLAC file or stream, following the fLaC ASCII file signature, one or more metadata blocks MUST be present before any audio frames appear. The first metadata block MUST be a streaminfo metadata block.", + "ja": "FLACファイルまたはストリームの開始時に、FLAC ASCIIファイルの署名に続いて、オーディオフレームが表示される前に1つ以上のメタデータブロックが存在する必要があります。最初のメタデータブロックは、Streaminfoメタデータブロックでなければなりません。" + }, + { + "indent": 0, + "text": "8.1. Metadata Block Header", + "section_title": true, + "ja": "8.1. メタデータブロックヘッダー" + }, + { + "indent": 3, + "text": "Each metadata block starts with a 4-byte header. The first bit in this header flags whether a metadata block is the last one. It is 0 when other metadata blocks follow; otherwise, it is 1. The 7 remaining bits of the first header byte contain the type of the metadata block as an unsigned number between 0 and 126, according to the following table. A value of 127 (i.e., 0b1111111) is forbidden. The three bytes that follow code for the size of the metadata block in bytes, excluding the 4 header bytes, as an unsigned number coded big-endian.", + "ja": "各メタデータブロックは、4バイトヘッダーで始まります。このヘッダーの最初のビットは、メタデータブロックが最後のブロックであるかどうかにかかわらず、フラグを立てます。他のメタデータブロックが続く場合は0です。それ以外の場合は、1です。最初のヘッダーバイトの残りの7ビットには、次の表によると、メタデータブロックのタイプが0〜126の間の符号なしの数値として含まれています。127の値（つまり、0B1111111）は禁止されています。メタデータブロックのサイズのコードに従う3バイトは、4つのヘッダーバイトを除く、符号なしの数字をコード化されたビッグエンディアンとして除外します。" + }, + { + "indent": 1, + "text": " +=========+=======================================================+\n | Value | Metadata Block Type |\n +=========+=======================================================+\n | 0 | Streaminfo |\n +---------+-------------------------------------------------------+\n | 1 | Padding |\n +---------+-------------------------------------------------------+\n | 2 | Application |\n +---------+-------------------------------------------------------+\n | 3 | Seek table |\n +---------+-------------------------------------------------------+\n | 4 | Vorbis comment |\n +---------+-------------------------------------------------------+\n | 5 | Cuesheet |\n +---------+-------------------------------------------------------+\n | 6 | Picture |\n +---------+-------------------------------------------------------+\n | 7 - 126 | Reserved |\n +---------+-------------------------------------------------------+\n | 127 | Forbidden (to avoid confusion with a frame sync code) |\n +---------+-------------------------------------------------------+\n\n Table 2", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "8.2. Streaminfo", + "section_title": true, + "ja": "8.2. Streaminfo" + }, + { + "indent": 3, + "text": "The streaminfo metadata block has information about the whole stream, such as sample rate, number of channels, total number of samples, etc. It MUST be present as the first metadata block in the stream. Other metadata blocks MAY follow. There MUST be no more than one streaminfo metadata block per FLAC stream.", + "ja": "Streaminfoメタデータブロックには、サンプルレート、チャネルの数、サンプルの総数など、ストリーム全体に関する情報があります。ストリームの最初のメタデータブロックとして存在する必要があります。他のメタデータブロックが続く場合があります。FLACストリームごとにStreaminfoメタデータブロックが1つしかない必要があります。" + }, + { + "indent": 3, + "text": "If the streaminfo metadata block contains incorrect or incomplete information, decoder behavior is left unspecified (i.e., it is up to the decoder implementation). A decoder MAY choose to stop further decoding when the information supplied by the streaminfo metadata block turns out to be incorrect or contains forbidden values. A decoder accepting information from the streaminfo metadata block (most significantly, the maximum frame size, maximum block size, number of audio channels, number of bits per sample, and total number of samples) without doing further checks during decoding of audio frames could be vulnerable to buffer overflows. See also Section 11.", + "ja": "Streaminfoメタデータブロックに誤った情報または不完全な情報が含まれている場合、デコーダーの動作は不特定のままになります（つまり、デコーダーの実装次第です）。Decoderは、Streaminfoメタデータブロックによって提供された情報が正しくないか、禁止された値が含まれていることが判明した場合、さらにデコードを停止することを選択できます。Streaminfoメタデータブロックからの情報を受け入れるデコーダー（最も重要なことは、最大フレームサイズ、最大ブロックサイズ、オーディオチャネル数、サンプルあたりのビット数、およびサンプルの総数）を選択せずに、オーディオフレームのデコード中にさらにチェックすることはできません。バッファオーバーフローに対して脆弱です。セクション11も参照してください。" + }, + { + "indent": 3, + "text": "The following table describes the streaminfo metadata block in order, excluding the metadata block header.", + "ja": "次の表は、メタデータブロックヘッダーを除く、Streaminfoメタデータブロックを順番に説明しています。" + }, + { + "indent": 4, + "text": " +========+=================================================+\n | Data | Description |\n +========+=================================================+\n | u(16) | The minimum block size (in samples) used in the |\n | | stream, excluding the last block. |\n +--------+-------------------------------------------------+\n | u(16) | The maximum block size (in samples) used in the |\n | | stream. |\n +--------+-------------------------------------------------+\n | u(24) | The minimum frame size (in bytes) used in the |\n | | stream. A value of 0 signifies that the value |\n | | is not known. |\n +--------+-------------------------------------------------+\n | u(24) | The maximum frame size (in bytes) used in the |\n | | stream. A value of 0 signifies that the value |\n | | is not known. |\n +--------+-------------------------------------------------+\n | u(20) | Sample rate in Hz. |\n +--------+-------------------------------------------------+\n | u(3) | (number of channels)-1. FLAC supports from 1 |\n | | to 8 channels. |\n +--------+-------------------------------------------------+\n | u(5) | (bits per sample)-1. FLAC supports from 4 to |\n | | 32 bits per sample. |\n +--------+-------------------------------------------------+\n | u(36) | Total number of interchannel samples in the |\n | | stream. A value of 0 here means the number of |\n | | total samples is unknown. |\n +--------+-------------------------------------------------+\n | u(128) | MD5 checksum of the unencoded audio data. This |\n | | allows the decoder to determine if an error |\n | | exists in the audio data even when, despite the |\n | | error, the bitstream itself is valid. A value |\n | | of 0 signifies that the value is not known. |\n +--------+-------------------------------------------------+\n\n Table 3", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "The minimum block size and the maximum block size MUST be in the 16-65535 range. The minimum block size MUST be equal to or less than the maximum block size.", + "ja": "最小ブロックサイズと最大ブロックサイズは、16-65535の範囲でなければなりません。最小ブロックサイズは、最大ブロックサイズ以下でなければなりません。" + }, + { + "indent": 3, + "text": "Any frame but the last one MUST have a block size equal to or greater than the minimum block size and MUST have a block size equal to or less than the maximum block size. The last frame MUST have a block size equal to or less than the maximum block size; it does not have to comply to the minimum block size because the block size of that frame must be able to accommodate the length of the audio data the stream contains.", + "ja": "最後のフレーム以外の任意のフレームには、最小ブロックサイズ以上のブロックサイズが必要であり、最大ブロックサイズ以下のブロックサイズが必要です。最後のフレームには、最大ブロックサイズ以下のブロックサイズが必要です。そのフレームのブロックサイズは、ストリームに含まれるオーディオデータの長さに対応できる必要があるため、最小ブロックサイズに準拠する必要はありません。" + }, + { + "indent": 3, + "text": "If the minimum block size is equal to the maximum block size, the file contains a fixed block size stream, as the minimum block size excludes the last block. Note that in the case of a stream with a variable block size, the actual maximum block size MAY be smaller than the maximum block size listed in the streaminfo metadata block, and the actual smallest block size excluding the last block MAY be larger than the minimum block size listed in the streaminfo metadata block. This is because the encoder has to write these fields before receiving any input audio data and cannot know beforehand what block sizes it will use, only between what bounds the block sizes will be chosen.", + "ja": "最小ブロックサイズが最大ブロックサイズに等しい場合、最小ブロックサイズは最後のブロックを除外するため、ファイルには固定ブロックサイズストリームが含まれます。可変ブロックサイズのストリームの場合、実際の最大ブロックサイズはStreaminfoメタデータブロックにリストされている最大ブロックサイズよりも小さく、最後のブロックを除く実際の最小のブロックサイズは最小値よりも大きい場合があることに注意してください。Streaminfoメタデータブロックにリストされているブロックサイズ。これは、入力オーディオデータを受信する前にエンコーダーがこれらのフィールドを記述する必要があり、使用するブロックサイズを事前に知ることができないためです。" + }, + { + "indent": 3, + "text": "The sample rate MUST NOT be 0 when the FLAC file contains audio. A sample rate of 0 MAY be used when non-audio is represented. This is useful if data is encoded that is not along a time axis or when the sample rate of the data lies outside the range that FLAC can represent in the streaminfo metadata block. If a sample rate of 0 is used, it is recommended to store the meaning of the encoded content in a Vorbis comment field (see Section 8.6) or an application metadata block (see Section 8.4). This document does not define such metadata.", + "ja": "FLACファイルにオーディオが含まれている場合、サンプルレートは0ではありません。非オーディオが表される場合、0のサンプルレートを使用できます。これは、時間軸に沿っていないデータがエンコードされている場合、またはデータのサンプルレートがFLACがStreaminfoメタデータブロックで表すことができる範囲外にある場合に役立ちます。0のサンプルレートを使用する場合は、エンコードされたコンテンツの意味をVorbisコメントフィールド（セクション8.6を参照）またはアプリケーションメタデータブロック（セクション8.4を参照）に保存することをお勧めします。このドキュメントは、そのようなメタデータを定義しません。" + }, + { + "indent": 3, + "text": "The MD5 checksum is computed by applying the MD5 message-digest algorithm in [RFC1321]. The message to this algorithm consists of all the samples of all channels interleaved, represented in signed, little-endian form. This interleaving is on a per-sample basis, so for a stereo file, this means the first sample of the first channel, then the first sample of the second channel, then the second sample of the first channel, etc. Before computing the checksum, all samples must be byte-aligned. If the bit depth is not a whole number of bytes, the value of each sample is sign-extended to the next whole number of bytes.", + "ja": "MD5チェックサムは、[RFC1321]にMD5メッセージダイジェストアルゴリズムを適用することにより計算されます。このアルゴリズムへのメッセージは、署名された小さなエンディアン形式で表されるインターリーブされたすべてのチャネルのすべてのサンプルで構成されています。このインターリーブはサンプルごとにあるため、ステレオファイルの場合、これは最初のチャネルの最初のサンプル、次に2番目のチャネルの最初のサンプル、次に最初のチャネルの2番目のサンプルなどを意味します。、すべてのサンプルをバイトアリーで整列する必要があります。ビットの深さがバイトの整数でない場合、各サンプルの値は、次のバイトの全部に標識拡張されます。" + }, + { + "indent": 3, + "text": "In the case of a 2-channel stream with 6-bit samples, bits will be lined up as follows:", + "ja": "6ビットサンプルを備えた2チャンネルストリームの場合、ビットは次のように並んでいます。" + }, + { + "indent": 3, + "text": "SSAAAAAASSBBBBBBSSCCCCCC\n^ ^ ^ ^ ^ ^\n| | | | | Bits of 2nd sample of 1st channel\n| | | | Sign extension bits of 2nd sample of 2nd channel\n| | | Bits of 1st sample of 2nd channel\n| | Sign extension bits of 1st sample of 2nd channel\n| Bits of 1st sample of 1st channel\nSign extension bits of 1st sample of 1st channel", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "In the case of a 1-channel stream with 12-bit samples, bits are lined up in little-endian byte order as follows:", + "ja": "12ビットサンプルを備えた1チャンネルストリームの場合、ビットは次のようにリトルエンディアンバイトの順序で並んでいます。" + }, + { + "indent": 3, + "text": "AAAAAAAASSSSAAAABBBBBBBBSSSSBBBB\n ^ ^ ^ ^ ^ ^\n | | | | | Most-significant 4 bits of 2nd sample\n | | | | Sign extension bits of 2nd sample\n | | | Least-significant 8 bits of 2nd sample\n | | Most-significant 4 bits of 1st sample\n | Sign extension bits of 1st sample\n Least-significant 8 bits of 1st sample", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "8.3. Padding", + "section_title": true, + "ja": "8.3. パディング" + }, + { + "indent": 3, + "text": "The padding metadata block allows for an arbitrary amount of padding. This block is useful when it is known that metadata will be edited after encoding; the user can instruct the encoder to reserve a padding block of sufficient size so that when metadata is added, it will simply overwrite the padding (which is relatively quick) instead of having to insert it into the existing file (which would normally require rewriting the entire file). There MAY be one or more padding metadata blocks per FLAC stream.", + "ja": "パディングメタデータブロックは、任意の量のパディングを可能にします。このブロックは、メタデータがエンコード後に編集されることがわかっている場合に役立ちます。ユーザーは、メタデータが追加されると、既存のファイルに挿入する代わりにパディング（比較的速い）を単純に上書きするように、エンコーダーに十分なサイズのパディングブロックを予約するように指示できます（通常は、書き換えが必要になります。ファイル全体）。FLACストリームごとに1つ以上のパディングメタデータブロックがある場合があります。" + }, + { + "indent": 3, + "text": " +======+======================================================+\n | Data | Description |\n +======+======================================================+\n | u(n) | n \"0\" bits (n MUST be a multiple of 8, i.e., a whole |\n | | number of bytes, and MAY be zero). n is 8 times the |\n | | size described in the metadata block header. |\n +------+------------------------------------------------------+\n\n Table 4", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "8.4. Application", + "section_title": true, + "ja": "8.4. 応用" + }, + { + "indent": 3, + "text": "The application metadata block is for use by third-party applications. The only mandatory field is a 32-bit application identifier (application ID). Application IDs are registered in the IANA \"FLAC Application Metadata Block IDs\" registry (see Section 12.2).", + "ja": "アプリケーションメタデータブロックは、サードパーティアプリケーションで使用するためのものです。唯一の必須フィールドは、32ビットアプリケーション識別子（アプリケーションID）です。アプリケーションIDは、IANA「FLACアプリケーションメタデータブロックID」レジストリに登録されています（セクション12.2を参照）。" + }, + { + "indent": 4, + "text": " +=======+===================================================+\n | Data | Description |\n +=======+===================================================+\n | u(32) | Registered application ID. |\n +-------+---------------------------------------------------+\n | u(n) | Application data (n MUST be a multiple of 8, |\n | | i.e., a whole number of bytes). n is 8 times the |\n | | size described in the metadata block header minus |\n | | the 32 bits already used for the application ID. |\n +-------+---------------------------------------------------+\n\n Table 5", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "8.5. Seek Table", + "section_title": true, + "ja": "8.5. テーブルを探します" + }, + { + "indent": 3, + "text": "The seek table metadata block can be used to store seek points. It is possible to seek to any given sample in a FLAC stream without a seek table, but the delay can be unpredictable since the bitrate may vary widely within a stream. By adding seek points to a stream, this delay can be significantly reduced. There MUST NOT be more than one seek table metadata block in a stream, but the table can have any number of seek points.", + "ja": "シークテーブルメタデータブロックを使用してシークポイントを保存できます。シークテーブルなしでFLACストリーム内の特定のサンプルを探すことは可能ですが、ビットレートはストリーム内で大きく異なるため、遅延は予測不可能になる可能性があります。ストリームにシークポイントを追加することにより、この遅延を大幅に減らすことができます。ストリームには1つ以上のシークテーブルメタデータブロックがありませんが、テーブルには任意の数のシークポイントがあります。" + }, + { + "indent": 3, + "text": "Each seek point takes 18 bytes, so a seek table with 1% resolution within a stream adds less than 2 kilobytes of data. The number of seek points is implied by the size described in the metadata block header, i.e., equal to size / 18. There is also a special \"placeholder\" seek point that will be ignored by decoders but can be used to reserve space for future seek point insertion.", + "ja": "各シークポイントには18バイトがかかるため、ストリーム内に1％の解像度を持つシークテーブルは、2キロバイト未満のデータを追加します。シークポイントの数は、メタデータブロックヘッダー、つまりサイズ / 18に等しいサイズによって暗示されます。また、デコーダーによって無視されるが、将来のためにスペースを予約するために使用できる特別な「プレースホルダー」シークポイントもあります。ポイント挿入を求めます。" + }, + { + "indent": 12, + "text": " +=============+=============================+\n | Data | Description |\n +=============+=============================+\n | Seek points | Zero or more seek points as |\n | | defined in Section 8.5.1. |\n +-------------+-----------------------------+\n\n Table 6", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "A seek table is generally not usable for seeking in a FLAC file embedded in a container (see Section 10), as such containers usually interleave FLAC data with other data and the offsets used in seek points are those of an unmuxed FLAC stream. Also, containers often provide their own seeking methods. However, it is possible to store the seek table in the container along with other metadata when muxing a FLAC file, so this stored seek table can be restored when demuxing the FLAC stream into a standalone FLAC file.", + "ja": "シークテーブルは、通常、コンテナに埋め込まれたFLACファイルを探すために使用できません（セクション10を参照）。そのようなコンテナは通常、FLACデータを他のデータとインターリーブし、シークポイントで使用されるオフセットは不合理なFLACストリームのものです。また、コンテナは多くの場合、独自のシーキング方法を提供します。ただし、FLACファイルをMuxingするときにSeekテーブルを他のメタデータとともにコンテナに保存することができます。そのため、FLACストリームをスタンドアロンFLACファイルに分類するときに、この保存されたシークテーブルを復元できます。" + }, + { + "indent": 0, + "text": "8.5.1. Seek Point", + "section_title": true, + "ja": "8.5.1. シークポイント" + }, + { + "indent": 0, + "text": "+=======+==========================================================+\n| Data | Description |\n+=======+==========================================================+\n| u(64) | Sample number of the first sample in the target frame or |\n| | 0xFFFFFFFFFFFFFFFF for a placeholder point. |\n+-------+----------------------------------------------------------+\n| u(64) | Offset (in bytes) from the first byte of the first frame |\n| | header to the first byte of the target frame's header. |\n+-------+----------------------------------------------------------+\n| u(16) | Number of samples in the target frame. |\n+-------+----------------------------------------------------------+\n\n Table 7", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Notes:", + "ja": "注：" + }, + { + "indent": 6, + "text": "* For placeholder points, the second and third field values are undefined.", + "ja": "* プレースホルダーポイントの場合、2番目と3番目のフィールド値は未定義です。" + }, + { + "indent": 6, + "text": "* Seek points within a table MUST be sorted in ascending order by sample number.", + "ja": "* テーブル内のシークポイントは、サンプル番号で昇順でソートする必要があります。" + }, + { + "indent": 6, + "text": "* Seek points within a table MUST be unique by sample number, with the exception of placeholder points.", + "ja": "* テーブル内のシークポイントは、プレースホルダーポイントを除き、サンプル番号で一意でなければなりません。" + }, + { + "indent": 6, + "text": "* The previous two notes imply that there MAY be any number of placeholder points, but they MUST all occur at the end of the table.", + "ja": "* 前の2つのメモは、プレースホルダーポイントの数が存在する可能性があることを意味しますが、それらはすべてテーブルの端で発生する必要があります。" + }, + { + "indent": 6, + "text": "* The sample offsets are those of an unmuxed FLAC stream. The offsets MUST NOT be updated on muxing to reflect the new offsets of FLAC frames in a container.", + "ja": "* サンプルオフセットは、不測のないFLACストリームのオフセットです。オフセットは、コンテナ内のFLACフレームの新しいオフセットを反映するために、マクシングで更新してはなりません。" + }, + { + "indent": 0, + "text": "8.6. Vorbis Comment", + "section_title": true, + "ja": "8.6. Vorbisコメント" + }, + { + "indent": 3, + "text": "A Vorbis comment metadata block contains human-readable information coded in UTF-8. The name \"Vorbis comment\" points to the fact that the Vorbis codec stores such metadata in almost the same way (see [Vorbis]). A Vorbis comment metadata block consists of a vendor string optionally followed by a number of fields, which are pairs of field names and field contents. The vendor string contains the name of the program that generated the file or stream. The fields contain metadata describing various aspects of the contained audio. Many users refer to these fields as \"FLAC tags\" or simply as \"tags\". A FLAC file MUST NOT contain more than one Vorbis comment metadata block.", + "ja": "Vorbisコメントメタデータブロックには、UTF-8でコーディングされた人間の読み取り可能な情報が含まれています。「Vorbis Comment」という名前は、Vorbis Codecがそのようなメタデータをほぼ同じ方法で保存するという事実を示しています（[Vorbis]を参照）。Vorbisコメントメタデータブロックは、オプションでフィールド名とフィールドのコンテンツのペアである多くのフィールドがオプションで続くベンダー文字列で構成されています。ベンダー文字列には、ファイルまたはストリームを生成したプログラムの名前が含まれています。フィールドには、含まれるオーディオのさまざまな側面を説明するメタデータが含まれています。多くのユーザーは、これらのフィールドを「FLACタグ」または単に「タグ」と呼んでいます。FLACファイルには、複数のVorbisコメントメタデータブロックを含めることはできません。" + }, + { + "indent": 3, + "text": "In a Vorbis comment metadata block, the metadata block header is directly followed by 4 bytes containing the length in bytes of the vendor string as an unsigned number coded little-endian. The vendor string follows, is UTF-8 coded and is not terminated in any way.", + "ja": "Vorbisコメントメタデータブロックでは、メタデータブロックヘッダーに直接続いて、ベンダー文字列の長さを符号なしの数字のコード化された小さなエンディアンとして含む4バイトが続きます。ベンダー文字列が続き、UTF-8コード化されており、いかなる方法でも終了しません。" + }, + { + "indent": 3, + "text": "Following the vendor string are 4 bytes containing the number of fields that are in the Vorbis comment block, stored as an unsigned number coded little-endian. If this number is non-zero, it is followed by the fields themselves, each of which is stored with a 4-byte length. For each field, the field length in bytes is stored as a 4-byte unsigned number coded little-endian. The field itself follows it. Like the vendor string, the field is UTF-8 coded and not terminated in any way.", + "ja": "ベンダーの文字列に続くのは、署名されていない番号コード化された小さなエンディアンとして保存されているVorbisコメントブロックにあるフィールドの数を含む4バイトです。この数値がゼロ以外の場合、フィールド自体が続き、それぞれが4バイトの長さで保存されます。各フィールドについて、バイト単位のフィールドの長さは、4バイトの符号なしの数字コード付きリトルエンディアンとして保存されます。フィールド自体がそれに続きます。ベンダー文字列のように、フィールドはUTF-8コード化されており、いかなる方法でも終了しません。" + }, + { + "indent": 3, + "text": "Each field consists of a field name and field contents, separated by an = character. The field name MUST only consist of UTF-8 code points U+0020 through U+007E, excluding U+003D, which is the = character. In other words, the field name can contain all printable ASCII characters except the equals sign. The evaluation of the field names MUST be case insensitive, so U+0041 through 0+005A (A-Z) MUST be considered equivalent to U+0061 through U+007A (a-z). The field contents can contain any UTF-8 character.", + "ja": "各フィールドは、AN =文字で区切られたフィールド名とフィールドの内容で構成されています。フィールド名は、U+003Dを除くUTF-8コードポイントU+0020からU+007Eからのみで構成されている必要があります。これは=文字です。言い換えれば、フィールド名には、Equals Signを除くすべての印刷可能なASCII文字を含めることができます。フィールド名の評価は症例ではないため、U+0041から0+005A（A-Z）は、U+0061からU+007A（A-Z）に相当すると見なす必要があります。フィールドの内容には、任意のUTF-8文字を含めることができます。" + }, + { + "indent": 3, + "text": "Note that the Vorbis comment as used in Vorbis allows for 2^64 bytes of data whereas the FLAC metadata block is limited to 2^24 bytes. Given the stated purpose of Vorbis comments, i.e., human-readable textual information, the FLAC metadata block limit is unlikely to be restrictive. Also, note that the 32-bit field lengths are coded little-endian as opposed to the usual big-endian coding of fixed-length integers in the rest of the FLAC format.", + "ja": "Vorbisで使用されているVorbisコメントは、2^64バイトのデータを許可するのに対し、FLACメタデータブロックは2^24バイトに制限されていることに注意してください。Vorbisのコメントの記載されている目的、つまり人間の読み取り可能なテキスト情報を考えると、FLACメタデータブロックの制限は制限されそうにありません。また、32ビットのフィールド長は、FLAC形式の残りの部分での固定整数の通常のビッグエンディアンコーディングとは対照的に、小さなエンディアンとコード化されていることに注意してください。" + }, + { + "indent": 0, + "text": "8.6.1. Standard Field Names", + "section_title": true, + "ja": "8.6.1. 標準フィールド名" + }, + { + "indent": 3, + "text": "Only one standard field name is defined: the channel mask field (see Section 8.6.2). No other field names are defined because the applicability of any field name is strongly tied to the content it is associated with. For example, field names that are useful for describing files that contain a single work of music would be unusable when labeling archived broadcasts, recordings of any kind, or a collection of music works. Even when describing a single work of music, different conventions exist depending on the kind of music: orchestral music differs from music by solo artists or bands.", + "ja": "定義されている標準フィールド名は1つだけです。チャネルマスクフィールド（セクション8.6.2を参照）。フィールド名の適用性が関連付けられているコンテンツに強く結び付けられているため、他のフィールド名は定義されていません。たとえば、アーカイブブロードキャスト、あらゆる種類の録音、音楽のコレクションにラベルを付ける場合、音楽の単一の作品を含むファイルを説明するのに役立つフィールド名は使用できません。音楽の単一の作品を説明するときでさえ、音楽の種類に応じて異なるコンベンションが存在します。オーケストラの音楽は、ソロアーティストやバンドの音楽とは異なります。" + }, + { + "indent": 3, + "text": "Despite the fact that no field names are formally defined, there is a general trend among devices and software capable of FLAC playback that are meant to play music. Most of those recognize at least the following field names:", + "ja": "正式に定義されているフィールド名はないという事実にもかかわらず、音楽を再生することを目的としたFLAC再生が可能なデバイスやソフトウェアの間に一般的な傾向があります。それらのほとんどは、少なくとも次のフィールド名を認識しています。" + }, + { + "indent": 3, + "text": "Title:", + "ja": "タイトル：" + }, + { + "indent": 12, + "text": "Name of the current work.", + "ja": "現在の作業の名前。" + }, + { + "indent": 3, + "text": "Artist:", + "ja": "アーティスト：" + }, + { + "indent": 12, + "text": "Name of the artist generally responsible for the current work. For orchestral works, this is usually the composer; otherwise, it is often the performer.", + "ja": "一般的に現在の作品を担当するアーティストの名前。オーケストラの作品にとって、これは通常作曲家です。そうでなければ、それはしばしばパフォーマーです。" + }, + { + "indent": 3, + "text": "Album:", + "ja": "アルバム：" + }, + { + "indent": 12, + "text": "Name of the collection the current work belongs to.", + "ja": "現在の作品が属するコレクションの名前。" + }, + { + "indent": 3, + "text": "For a more comprehensive list of possible field names suited for describing a single work of music in various genres, the list of tags used in the MusicBrainz project is suggested; see [MusicBrainz].", + "ja": "さまざまなジャンルで音楽の単一の作品を説明するのに適したフィールド名のより包括的なリストのリストについては、MusicBrainzプロジェクトで使用されるタグのリストが提案されています。[MusicBrainz]を参照してください。" + }, + { + "indent": 0, + "text": "8.6.2. Channel Mask", + "section_title": true, + "ja": "8.6.2. チャンネルマスク" + }, + { + "indent": 3, + "text": "Besides fields containing information about the work itself, one field is defined for technical reasons: WAVEFORMATEXTENSIBLE_CHANNEL_MASK. This field is used to communicate that the channels in a file differ from the default channels defined in Section 9.1.3. For example, by default, a FLAC file containing two channels is interpreted to contain a left and right channel, but with this field, it is possible to describe different channel contents.", + "ja": "作業自体に関する情報を含むフィールドに加えて、1つのフィールドは、技術的な理由で定義されています：waveformatextensible_channel_mask。このフィールドは、ファイル内のチャネルがセクション9.1.3で定義されているデフォルトチャネルと異なることを通信するために使用されます。たとえば、デフォルトでは、2つのチャネルを含むFLACファイルが左右のチャネルが含まれていると解釈されますが、このフィールドでは、異なるチャネルの内容を記述することができます。" + }, + { + "indent": 3, + "text": "The channel mask consists of flag bits indicating which channels are present. The flags only signal which channels are present, not in which order, so if a file to be encoded has channels that are ordered differently, they have to be reordered. This mask is stored with a hexadecimal representation preceded by 0x; see the examples below. Please note that a file in which the channel order is defined through the WAVEFORMATEXTENSIBLE_CHANNEL_MASK is not streamable (see Section 7), as the field is not found in each frame header. The mask bits can be found in the following table.", + "ja": "チャネルマスクは、どのチャネルが存在するかを示すフラグビットで構成されています。フラグは、どのチャネルが存在するかのみの信号のみであり、どの順序ではないため、エンコードされるファイルに異なる方法で注文されるチャネルがある場合、それらを再注文する必要があります。このマスクは、0xが先行する16進表現で保存されています。以下の例を参照してください。各フレームヘッダーにフィールドが見つからないため、チャネル順序がwaveformatextensible_channel_maskを介して定義されるファイル（セクション7を参照）に注意してください。マスクビットは次の表にあります。" + }, + { + "indent": 12, + "text": " +============+=============================+\n | Bit Number | Channel Description |\n +============+=============================+\n | 0 | Front left |\n +------------+-----------------------------+\n | 1 | Front right |\n +------------+-----------------------------+\n | 2 | Front center |\n +------------+-----------------------------+\n | 3 | Low-frequency effects (LFE) |\n +------------+-----------------------------+\n | 4 | Back left |\n +------------+-----------------------------+\n | 5 | Back right |\n +------------+-----------------------------+\n | 6 | Front left of center |\n +------------+-----------------------------+\n | 7 | Front right of center |\n +------------+-----------------------------+\n | 8 | Back center |\n +------------+-----------------------------+\n | 9 | Side left |\n +------------+-----------------------------+\n | 10 | Side right |\n +------------+-----------------------------+\n | 11 | Top center |\n +------------+-----------------------------+\n | 12 | Top front left |\n +------------+-----------------------------+\n | 13 | Top front center |\n +------------+-----------------------------+\n | 14 | Top front right |\n +------------+-----------------------------+\n | 15 | Top rear left |\n +------------+-----------------------------+\n | 16 | Top rear center |\n +------------+-----------------------------+\n | 17 | Top rear right |\n +------------+-----------------------------+\n\n Table 8", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Following are three examples:", + "ja": "以下は3つの例です。" + }, + { + "indent": 6, + "text": "* A file has a single channel -- an LFE channel. The Vorbis comment field is WAVEFORMATEXTENSIBLE_CHANNEL_MASK=0x8.", + "ja": "* ファイルには、LFEチャネルという単一のチャネルがあります。Vorbisのコメントフィールドはwaveformatextensible_channel_mask = 0x8です。" + }, + { + "indent": 6, + "text": "* A file has four channels -- front left, front right, top front left, and top front right. The Vorbis comment field is WAVEFORMATEXTENSIBLE_CHANNEL_MASK=0x5003.", + "ja": "* ファイルには4つのチャネルがあります。左前面、前面、左上、左上、右上右上部。Vorbisのコメントフィールドは波形xtensible_channel_mask = 0x5003です。" + }, + { + "indent": 6, + "text": "* An input has four channels -- back center, top front center, front center, and top rear center in that order. These have to be reordered to front center, back center, top front center, and top rear center. The Vorbis comment field added is WAVEFORMATEXTENSIBLE_CHANNEL_MASK=0x12104.", + "ja": "* 入力には、その順序でバックセンター、トップフロントセンター、フロントセンター、トップリアセンターの4つのチャネルがあります。これらは、フロントセンター、バックセンター、トップフロントセンター、トップリアセンターに並べ替える必要があります。追加されたVorbisのコメントフィールドは、waveformatextensible_channel_mask = 0x12104です。" + }, + { + "indent": 3, + "text": "WAVEFORMATEXTENSIBLE_CHANNEL_MASK fields MAY be padded with zeros, for example, 0x0008 for a single LFE channel. Parsing of WAVEFORMATEXTENSIBLE_CHANNEL_MASK fields MUST be case-insensitive for both the field name and the field contents.", + "ja": "WaveFormateXtensible_Channel_Maskフィールドには、単一のLFEチャネルで0x0008など、ゼロがパッドで埋められている場合があります。WaveFormateXtensible_Channel_Maskフィールドの解析は、フィールド名とフィールドの内容の両方でケース非感受性でなければなりません。" + }, + { + "indent": 3, + "text": "A WAVEFORMATEXTENSIBLE_CHANNEL_MASK field of 0x0 can be used to indicate that none of the audio channels of a file correlate with speaker positions. This is the case when audio needs to be decoded into speaker positions (e.g., Ambisonics B-format audio) or when a multitrack recording is contained.", + "ja": "0x0の波形Xtensible_channel_maskフィールドを使用して、ファイルのオーディオチャネルがスピーカーの位置と相関していないことを示すことができます。これは、オーディオをスピーカーの位置にデコードする必要がある場合（たとえば、Ambisonics B-Format Audio）、またはマルチトラックの録音が含まれている場合です。" + }, + { + "indent": 3, + "text": "It is possible for a WAVEFORMATEXTENSIBLE_CHANNEL_MASK field to code for fewer channels than are present in the audio. If that is the case, the remaining channels SHOULD NOT be rendered by a playback application unfamiliar with their purpose. For example, the Ambisonics UHJ format is compatible with stereo playback: its first two channels can be played back on stereo equipment, but all four channels together can be decoded into surround sound. For that example, the Vorbis comment field WAVEFORMATEXTENSIBLE_CHANNEL_MASK=0x3 would be set, indicating that the first two channels are front left and front right and other channels do not correlate with speaker positions directly.", + "ja": "波形Xtensible_Channel_Maskフィールドが、音声に存在するよりも少ないチャネルをコードすることができます。その場合、残りのチャネルは、目的に不慣れな再生アプリケーションによってレンダリングされるべきではありません。たとえば、Ambisonics UHJ形式はステレオ再生と互換性があります。最初の2つのチャネルはステレオ機器で再生できますが、4つのチャネルはすべて一緒にサラウンドサウンドにデコードできます。その例では、Vorbisのコメントフィールドwaveformatextensible_channel_mask = 0x3が設定され、最初の2つのチャネルが左前面と正面右であり、他のチャネルがスピーカーの位置と直接相関しないことを示します。" + }, + { + "indent": 3, + "text": "If audio channels not assigned to any speaker are contained and decoding to speaker positions is possible, it is recommended to provide metadata on how this decoding should take place in another Vorbis comment field or an application metadata block. This document does not define such metadata.", + "ja": "スピーカーに割り当てられていないオーディオチャネルが含まれており、スピーカーの位置にデコードすることが可能な場合は、別のVorbisコメントフィールドまたはアプリケーションメタデータブロックでこのデコードがどのように行われるかについてメタデータを提供することをお勧めします。このドキュメントは、そのようなメタデータを定義しません。" + }, + { + "indent": 0, + "text": "8.7. Cuesheet", + "section_title": true, + "ja": "8.7. キューシート" + }, + { + "indent": 3, + "text": "A cuesheet metadata block can be used either to store the track and index point structure of a Compact Disc Digital Audio (CD-DA) along with its audio or to provide a mechanism to store locations of interest within a FLAC file. Certain aspects of this metadata block come directly from the CD-DA specification (called Red Book), which is standardized as [IEC.60908.1999]. The description below is complete, and further reference to [IEC.60908.1999] is not needed to implement this metadata block.", + "ja": "キューシートメタデータブロックを使用して、コンパクトディスクデジタルオーディオ（CD-DA）のトラックおよびインデックスポイント構造をオーディオとともに保存するか、FLACファイル内に関心のある場所を保存するメカニズムを提供することができます。このメタデータブロックの特定の側面は、[IEC.60908.1999]として標準化されているCD-DA仕様（Red Bookと呼ばれる）から直接届きます。以下の説明は完全であり、このメタデータブロックを実装するために[IEC.60908.1999]へのさらなる参照は必要ありません。" + }, + { + "indent": 3, + "text": "The structure of a cuesheet metadata block is enumerated in the following table.", + "ja": "キューシートメタデータブロックの構造は、次の表に列挙されています。" + }, + { + "indent": 0, + "text": "+============+======================================================+\n| Data | Description |\n+============+======================================================+\n| u(128*8) | Media catalog number in ASCII |\n| | printable characters 0x20-0x7E. |\n+------------+------------------------------------------------------+\n| u(64) | Number of lead-in samples. |\n+------------+------------------------------------------------------+\n| u(1) | 1 if the cuesheet corresponds to a |\n| | CD-DA; else 0. |\n+------------+------------------------------------------------------+\n| u(7+258*8) | Reserved. All bits MUST be set to |\n| | zero. |\n+------------+------------------------------------------------------+\n| u(8) | Number of tracks in this cuesheet. |\n+------------+------------------------------------------------------+\n| Cuesheet | A number of structures as specified |\n| tracks | in Section 8.7.1 equal to the number |\n| | of tracks specified previously. |\n+------------+------------------------------------------------------+\n\n Table 9", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "If the media catalog number is less than 128 bytes long, it is right-padded with 0x00 bytes. For CD-DA, this is a 13-digit number followed by 115 0x00 bytes.", + "ja": "メディアカタログ番号の長さが128バイト未満の場合、0x00バイトで右パッドが付いています。CD-DAの場合、これは13桁の数字に続いて115 0x00バイトです。" + }, + { + "indent": 3, + "text": "The number of lead-in samples has meaning only for CD-DA cuesheets; for other uses, it should be 0. For CD-DA, the lead-in is the TRACK 00 area where the table of contents is stored; more precisely, it is the number of samples from the first sample of the media to the first sample of the first index point of the first track. According to [IEC.60908.1999], the lead-in MUST be silent, and CD grabbing software does not usually store it; additionally, the lead-in MUST be at least two seconds but MAY be longer. For these reasons, the lead-in length is stored here so that the absolute position of the first track can be computed. Note that the lead-in stored here is the number of samples up to the first index point of the first track, not necessarily to INDEX 01 of the first track; even the first track MAY have INDEX 00 data.", + "ja": "リードインサンプルの数は、CD-DAキューシートのみを意味します。他の用途の場合、それは0でなければなりません。CD-DAの場合、リードインは目次が保存されているトラック00エリアです。より正確には、メディアの最初のサンプルから最初のトラックの最初のインデックスポイントの最初のサンプルまでのサンプルの数です。[IEC.60908.1999]によれば、リードインは沈黙している必要があり、CDグラブするソフトウェアは通常保存しません。さらに、リードインは少なくとも2秒でなければなりませんが、長くなる必要があります。これらの理由により、最初のトラックの絶対位置を計算できるように、リードインの長さがここに保存されます。ここに保存されているリードインは、最初のトラックの最初のトラックの最初のインデックスポイントまでのサンプルの数であり、必ずしも最初のトラックの01インデックスではありません。最初のトラックでさえ、インデックス00データがある場合があります。" + }, + { + "indent": 3, + "text": "The number of tracks MUST be at least 1, as a cuesheet block MUST have a lead-out track. For CD-DA, this number MUST be no more than 100 (99 regular tracks and one lead-out track). The lead-out track is always the last track in the cuesheet. For CD-DA, the lead-out track number MUST be 170 as specified by [IEC.60908.1999]; otherwise, it MUST be 255.", + "ja": "キューシートブロックにはリードアウトトラックが必要なため、トラックの数は少なくとも1でなければなりません。CD-DAの場合、この数値は100（99の通常のトラックと1つのリードアウトトラック）を超えている必要があります。リードアウトトラックは、常にキューシートの最後のトラックです。CD-DAの場合、[IEC.60908.1999]で指定されているように、リードアウトトラック番号は170でなければなりません。それ以外の場合は、255でなければなりません。" + }, + { + "indent": 0, + "text": "8.7.1. Cuesheet Track", + "section_title": true, + "ja": "8.7.1. キューシートトラック" + }, + { + "indent": 0, + "text": "+=============+=====================================================+\n| Data | Description |\n+=============+=====================================================+\n| u(64) | Track offset of the first index point in |\n| | samples, relative to the beginning of the |\n| | FLAC audio stream. |\n+-------------+-----------------------------------------------------+\n| u(8) | Track number. |\n+-------------+-----------------------------------------------------+\n| u(12*8) | Track ISRC. |\n+-------------+-----------------------------------------------------+\n| u(1) | The track type: 0 for audio, 1 for non-audio. |\n| | This corresponds to the CD-DA Q-channel |\n| | control bit 3. |\n+-------------+-----------------------------------------------------+\n| u(1) | The pre-emphasis flag: 0 for no pre-emphasis, |\n| | 1 for pre-emphasis. This corresponds to the |\n| | CD-DA Q-channel control bit 5. |\n+-------------+-----------------------------------------------------+\n| u(6+13*8) | Reserved. All bits MUST be set to zero. |\n+-------------+-----------------------------------------------------+\n| u(8) | The number of track index points. |\n+-------------+-----------------------------------------------------+\n| Cuesheet | For all tracks except the lead-out track, a |\n| track index | number of structures as specified in |\n| points | Section 8.7.1.1 equal to the number of index |\n| | points specified previously. |\n+-------------+-----------------------------------------------------+\n\n Table 10", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Note that the track offset differs from the one in CD-DA, where the track's offset in the table of contents (TOC) is that of the track's INDEX 01 even if there is an INDEX 00. For CD-DA, the track offset MUST be evenly divisible by 588 samples (588 samples = 44100 samples/ s * 1/75 s).", + "ja": "トラックオフセットはCD-DAのものとは異なります。このテーブル（TOC）におけるトラックのオフセットは、インデックス00がある場合でもトラックのインデックス01のものです。CD-DAの場合、トラックオフセットは必要です588サンプル（588サンプル= 44100サンプル/ s * 1/75秒）で均等に分裂します。" + }, + { + "indent": 3, + "text": "A track number of 0 is not allowed because the CD-DA specification reserves this for the lead-in. For CD-DA, the number MUST be 1-99 or 170 for the lead-out; for non-CD-DA, the track number MUST be 255 for the lead-out. It is recommended to start with track 1 and increase sequentially. Track numbers MUST be unique within a cuesheet.", + "ja": "CD-DA仕様がリードイン用にこれを予約するため、トラック番号0は許可されていません。CD-DAの場合、リードアウトの場合、数は1-99または170でなければなりません。非CD-DAの場合、トラック番号はリードアウトの場合は255でなければなりません。トラック1から開始し、順次増加することをお勧めします。トラック番号は、キューシート内で一意でなければなりません。" + }, + { + "indent": 3, + "text": "The track ISRC (International Standard Recording Code) is a 12-digit alphanumeric code; see [ISRC-handbook]. A value of 12 ASCII 0x00 characters MAY be used to denote the absence of an ISRC.", + "ja": "トラックISRC（International Standard Recording Code）は、12桁の英数字コードです。[ISRCハンドブック]を参照してください。12個のASCII 0x00文字の値を使用して、ISRCの欠如を示すことができます。" + }, + { + "indent": 3, + "text": "There MUST be at least one index point in every track in a cuesheet except for the lead-out track, which MUST have zero. For CD-DA, the number of index points MUST NOT be more than 100.", + "ja": "キューシートのすべてのトラックには、リードアウトトラックを除いて、ゼロが必要なものがないことを除いて、少なくとも1つのインデックスポイントが必要です。CD-DAの場合、インデックスポイントの数は100を超えてはなりません。" + }, + { + "indent": 0, + "text": "8.7.1.1. Cuesheet Track Index Point", + "section_title": true, + "ja": "8.7.1.1. Cuesheetトラックインデックスポイント" + }, + { + "indent": 11, + "text": " +========+====================================+\n | Data | Description |\n +========+====================================+\n | u(64) | Offset in samples, relative to the |\n | | track offset, of the index point. |\n +--------+------------------------------------+\n | u(8) | The track index point number. |\n +--------+------------------------------------+\n | u(3*8) | Reserved. All bits MUST be set to |\n | | zero. |\n +--------+------------------------------------+\n\n Table 11", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "For CD-DA, the track index point offset MUST be evenly divisible by 588 samples (588 samples = 44100 samples/s * 1/75 s). Note that the offset is from the beginning of the track, not the beginning of the audio data.", + "ja": "CD-DAの場合、トラックインデックスポイントオフセットは588サンプル（588サンプル= 44100サンプル/s * 1/75秒）で均等に分割できる必要があります。オフセットは、オーディオデータの開始ではなく、トラックの開始からのものであることに注意してください。" + }, + { + "indent": 3, + "text": "For CD-DA, a track index point number of 0 corresponds to the track pre-gap. The first index point in a track MUST have a number of 0 or 1, and subsequently, index point numbers MUST increase by 1. Index point numbers MUST be unique within a track.", + "ja": "CD-DAの場合、トラックインデックスポイント番号0は、トラックのプレギャップに対応します。トラックの最初のインデックスポイントには0または1が多数ある必要があり、その後、インデックスポイント番号が1増加する必要があります。インデックスポイント番号はトラック内で一意でなければなりません。" + }, + { + "indent": 0, + "text": "8.8. Picture", + "section_title": true, + "ja": "8.8. 写真" + }, + { + "indent": 3, + "text": "The picture metadata block contains image data of a picture in some way belonging to the audio contained in the FLAC file. Its format is derived from the Attached Picture (APIC) frame in the ID3v2 specification; see [ID3v2]. However, contrary to the APIC frame in ID3v2, the media type and description are prepended with a 4-byte length field instead of being 0x00 delimited strings. A FLAC file MAY contain one or more picture metadata blocks.", + "ja": "画像メタデータブロックには、FLACファイルに含まれるオーディオに属する何らかの方法で、画像の画像データが含まれています。その形式は、ID3v2仕様の添付画像（APIC）フレームから派生しています。[id3v2]を参照してください。ただし、ID3v2のAPICフレームとは反対に、メディアタイプと説明は、0x00の区切り文字列ではなく、4バイトの長さフィールドで準備されています。FLACファイルには、1つ以上の画像メタデータブロックが含まれる場合があります。" + }, + { + "indent": 3, + "text": "Note that while the length fields for media type, description, and picture data are 4 bytes in length and could code for a size up to 4 GiB in theory, the total metadata block size cannot exceed what can be described by the metadata block header, i.e., 16 MiB.", + "ja": "メディアタイプ、説明、および画像データの長さフィールドの長さは4バイトで、理論的には最大4ギブのサイズをコーディングできますが、メタデータブロックサイズの合計はメタデータブロックヘッダーで説明できるものを超えることはできないことに注意してください。すなわち、16ミブ。" + }, + { + "indent": 3, + "text": "Instead of picture data, the picture metadata block can also contain a URI as described in [RFC3986].", + "ja": "画像データの代わりに、[RFC3986]に記載されているように、画像メタデータブロックにもURIを含めることができます。" + }, + { + "indent": 3, + "text": "The structure of a picture metadata block is enumerated in the following table.", + "ja": "画像メタデータブロックの構造は、次の表に列挙されています。" + }, + { + "indent": 0, + "text": "+========+==========================================================+\n| Data | Description |\n+========+==========================================================+\n| u(32) | The picture type according to Table 13. |\n+--------+----------------------------------------------------------+\n| u(32) | The length of the media type string in bytes. |\n+--------+----------------------------------------------------------+\n| u(n*8) | The media type string as specified by [RFC2046], |\n| | or the text string --> to signify that the data |\n| | part is a URI of the picture instead of the |\n| | picture data itself. This field must be in |\n| | printable ASCII characters 0x20-0x7E. |\n+--------+----------------------------------------------------------+\n| u(32) | The length of the description string in bytes. |\n+--------+----------------------------------------------------------+\n| u(n*8) | The description of the picture in UTF-8. |\n+--------+----------------------------------------------------------+\n| u(32) | The width of the picture in pixels. |\n+--------+----------------------------------------------------------+\n| u(32) | The height of the picture in pixels. |\n+--------+----------------------------------------------------------+\n| u(32) | The color depth of the picture in bits per |\n| | pixel. |\n+--------+----------------------------------------------------------+\n| u(32) | For indexed-color pictures (e.g., GIF), the |\n| | number of colors used; 0 for non-indexed |\n| | pictures. |\n+--------+----------------------------------------------------------+\n| u(32) | The length of the picture data in bytes. |\n+--------+----------------------------------------------------------+\n| u(n*8) | The binary picture data. |\n+--------+----------------------------------------------------------+\n\n Table 12", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "The height, width, color depth, and \"number of colors\" fields are for informational purposes only. Applications MUST NOT use them in decoding the picture or deciding how to display it, but applications MAY use them to decide whether or not to process a block (e.g., when selecting between different picture blocks) and MAY show them to the user. If a picture has no concept for any of these fields (e.g., vector images may not have a height or width in pixels) or the content of any field is unknown, the affected fields MUST be set to zero.", + "ja": "高さ、幅、色の深さ、「色の数」フィールドは、情報目的のみを目的としています。アプリケーションは、画像のデコードや表示方法の決定にそれらを使用してはなりませんが、アプリケーションはそれらを使用してブロックを処理するかどうか（例：異なる画像ブロック間を選択するとき）を決定し、ユーザーに表示する場合があります。これらのフィールドのいずれかの概念がない場合（たとえば、ベクトル画像にピクセルで高さや幅がない場合があります）、または任意のフィールドの内容が不明である場合、影響を受けるフィールドはゼロに設定する必要があります。" + }, + { + "indent": 3, + "text": "The following table contains all the defined picture types. Values other than those listed in the table are reserved. There MAY only be one each of picture types 1 and 2 in a file. In general practice, many FLAC playback devices and software display the contents of a picture metadata block, if present, with picture type 3 (front cover) during playback.", + "ja": "次の表には、定義されたすべての画像タイプが含まれています。テーブルにリストされている値以外の値は予約されています。ファイルには、それぞれの画像タイプ1と2のみが1つしかありません。一般的には、多くのFLAC再生デバイスとソフトウェアが、再生中に画像タイプ3（フロントカバー）を備えた画像メタデータブロックの内容を表示します。" + }, + { + "indent": 5, + "text": " +=======+=================================================+\n | Value | Picture Type |\n +=======+=================================================+\n | 0 | Other |\n +-------+-------------------------------------------------+\n | 1 | PNG file icon of 32x32 pixels (see [RFC2083]) |\n +-------+-------------------------------------------------+\n | 2 | General file icon |\n +-------+-------------------------------------------------+\n | 3 | Front cover |\n +-------+-------------------------------------------------+\n | 4 | Back cover |\n +-------+-------------------------------------------------+\n | 5 | Liner notes page |\n +-------+-------------------------------------------------+\n | 6 | Media label (e.g., CD, Vinyl or Cassette label) |\n +-------+-------------------------------------------------+\n | 7 | Lead artist, lead performer, or soloist |\n +-------+-------------------------------------------------+\n | 8 | Artist or performer |\n +-------+-------------------------------------------------+\n | 9 | Conductor |\n +-------+-------------------------------------------------+\n | 10 | Band or orchestra |\n +-------+-------------------------------------------------+\n | 11 | Composer |\n +-------+-------------------------------------------------+\n | 12 | Lyricist or text writer |\n +-------+-------------------------------------------------+\n | 13 | Recording location |\n +-------+-------------------------------------------------+\n | 14 | During recording |\n +-------+-------------------------------------------------+\n | 15 | During performance |\n +-------+-------------------------------------------------+\n | 16 | Movie or video screen capture |\n +-------+-------------------------------------------------+\n | 17 | A bright colored fish |\n +-------+-------------------------------------------------+\n | 18 | Illustration |\n +-------+-------------------------------------------------+\n | 19 | Band or artist logotype |\n +-------+-------------------------------------------------+\n | 20 | Publisher or studio logotype |\n +-------+-------------------------------------------------+\n\n Table 13", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "The origin and use of value 17 (\"A bright colored fish\") is unclear. This was copied to maintain compatibility with ID3v2. Applications are discouraged from offering this value to users when embedding a picture.", + "ja": "値17（「明るい色の魚」）の起源と使用は不明です。これは、ID3v2との互換性を維持するためにコピーされました。アプリケーションは、写真を埋め込むときにユーザーにこの価値を提供することを思いとどまらせます。" + }, + { + "indent": 3, + "text": "If a URI (not a picture) is contained in this block, the following points apply:", + "ja": "このブロックにURI（写真ではない）が含まれている場合、次のポイントが適用されます。" + }, + { + "indent": 6, + "text": "* The URI can be in either absolute or relative form. If a URI is in relative form, it is related to the URI of the FLAC content processed.", + "ja": "* URIは、絶対的または相対的な形式になります。URIが相対的な形である場合、それは処理されたFLAC含有量のURIに関連しています。" + }, + { + "indent": 6, + "text": "* Applications MUST obtain explicit user approval to retrieve images via remote protocols and to retrieve local images that are not located in the same directory as the FLAC file being processed.", + "ja": "* アプリケーションは、リモートプロトコルを介して画像を取得し、処理されているFLACファイルと同じディレクトリにないローカル画像を取得するために、明示的なユーザー承認を取得する必要があります。" + }, + { + "indent": 6, + "text": "* Applications supporting linked images MUST handle unavailability of URIs gracefully. They MAY report unavailability to the user.", + "ja": "* リンクされた画像をサポートするアプリケーションは、URIの不可能性を優雅に処理する必要があります。ユーザーに利用不能を報告する場合があります。" + }, + { + "indent": 6, + "text": "* Applications MAY reject processing URIs for any reason, particularly for security or privacy reasons.", + "ja": "* アプリケーションは、特にセキュリティまたはプライバシーの理由により、何らかの理由でURIの処理を拒否する場合があります。" + }, + { + "indent": 0, + "text": "9. Frame Structure", + "section_title": true, + "ja": "9. フレーム構造" + }, + { + "indent": 3, + "text": "One or more frames follow directly after the last metadata block. Each frame consists of a frame header, one or more subframes, padding zero bits to achieve byte alignment, and a frame footer. The number of subframes in each frame is equal to the number of audio channels.", + "ja": "最後のメタデータブロックの直後に1つ以上のフレームが続きます。各フレームは、フレームヘッダー、1つ以上のサブフレーム、バイトアライメントを実現するためにゼロビットをパディングする、およびフレームフッターで構成されています。各フレームのサブフレームの数は、オーディオチャネルの数に等しくなります。" + }, + { + "indent": 3, + "text": "Each frame header stores the audio sample rate, number of bits per sample, and number of channels independently of the streaminfo metadata block and other frame headers. This was done to permit multicasting of FLAC files, but it also allows these properties to change mid-stream. Because not all environments in which FLAC decoders are used are able to cope with changes to these properties during playback, a decoder MAY choose to stop decoding on such a change. A decoder that does not check for such a change could be vulnerable to buffer overflows. See also Section 11.", + "ja": "各フレームヘッダーは、オーディオサンプルレート、サンプルあたりのビット数、およびStreaminfoメタデータブロックおよびその他のフレームヘッダーとは無関係にチャネルの数を保存します。これは、FLACファイルのマルチキャストを許可するために行われましたが、これらのプロパティが中間ストリームを変更することもできます。FLACデコーダーが使用されるすべての環境が再生中にこれらのプロパティの変更に対処できるわけではないため、デコーダーはそのような変更のデコードを停止することを選択できます。このような変更をチェックしないデコーダーは、バッファーオーバーフローに対して脆弱です。セクション11も参照してください。" + }, + { + "indent": 3, + "text": "Note that storing audio with changing audio properties in FLAC results in various practical problems. For example, these changes of audio properties must happen on a frame boundary or the process will not be lossless. When a variable block size is chosen to accommodate this, note that blocks smaller than 16 samples are not allowed; therefore, it is not possible to store an audio stream in which these properties change within 16 samples of the last change or the start of the file. Also, since the streaminfo metadata block can only accommodate a single set of properties, it is only valid for part of such an audio stream. Instead, it is RECOMMENDED to store an audio stream with changing properties in FLAC encapsulated in a container capable of handling such changes, as these do not suffer from the mentioned limitations. See Section 10 for details.", + "ja": "FLACのオーディオプロパティの変更でオーディオを保存すると、さまざまな実際的な問題が発生することに注意してください。たとえば、これらのオーディオプロパティの変更は、フレームの境界で発生する必要があります。または、プロセスがロスレスではありません。これに対応するために可変ブロックサイズが選択されている場合、16個未満のサンプルが許可されていないことに注意してください。したがって、これらのプロパティが最後の変更またはファイルの開始の16サンプル内で変更されるオーディオストリームを保存することはできません。また、Streaminfoメタデータブロックは単一のプロパティのみにのみ対応できるため、このようなオーディオストリームの一部にのみ有効です。代わりに、このような変更を処理できるコンテナにカプセル化されたFLACのプロパティの変更を伴うオーディオストリームを保存することをお勧めします。詳細については、セクション10を参照してください。" + }, + { + "indent": 0, + "text": "9.1. Frame Header", + "section_title": true, + "ja": "9.1. フレームヘッダー" + }, + { + "indent": 3, + "text": "Each frame MUST start on a byte boundary and start with the 15-bit frame sync code 0b111111111111100. Following the sync code is the blocking strategy bit, which MUST NOT change during the audio stream. The blocking strategy bit is 0 for a fixed block size stream or 1 for a variable block size stream. If the blocking strategy is known, a decoder can include this bit when searching for the start of a frame to reduce the possibility of encountering a false positive, as the first two bytes of a frame are either 0xFFF8 for a fixed block size stream or 0xFFF9 for a variable block size stream.", + "ja": "各フレームはバイト境界で開始し、15ビットフレーム同期コード0B111111111111100から開始する必要があります。同期コードに従うことは、ブロッキング戦略ビットです。これは、オーディオストリーム中に変更してはなりません。ブロッキング戦略ビットは、固定ブロックサイズのストリームの場合は0、可変ブロックサイズストリームの場合は1です。ブロッキング戦略がわかっている場合、デコーダーはフレームの開始を検索するときにこのビットを含めることができます。フレームの最初の2バイトは固定ブロックサイズストリームの0xfff8または0xfff9のいずれかであるため、可変ブロックサイズのストリームの場合。" + }, + { + "indent": 0, + "text": "9.1.1. Block Size Bits", + "section_title": true, + "ja": "9.1.1. ブロックサイズビット" + }, + { + "indent": 3, + "text": "Following the frame sync code and blocking strategy bit are 4 bits (the first 4 bits of the third byte of each frame) referred to as the block size bits. Their value relates to the block size according to the following table, where v is the value of the 4 bits as an unsigned number. If the block size bits code for an uncommon block size, this is stored after the coded number; see Section 9.1.6.", + "ja": "フレームの同期コードとブロッキング戦略ビットに続くのは、ブロックサイズビットと呼ばれる4ビット（各フレームの3番目のバイトの最初の4ビット）です。それらの値は、次の表に従ってブロックサイズに関連しています。ここで、Vは署名されていない数値として4ビットの値です。ブロックサイズが珍しいブロックサイズのコードをビットする場合、これはコード化された数字の後に保存されます。セクション9.1.6を参照してください。" + }, + { + "indent": 2, + "text": " +=================+=============================================+\n | Value | Block Size |\n +=================+=============================================+\n | 0b0000 | Reserved |\n +-----------------+---------------------------------------------+\n | 0b0001 | 192 |\n +-----------------+---------------------------------------------+\n | 0b0010 - 0b0101 | 144 * (2^v), i.e., 576, 1152, 2304, or 4608 |\n +-----------------+---------------------------------------------+\n | 0b0110 | Uncommon block size minus 1, stored as an |\n | | 8-bit number |\n +-----------------+---------------------------------------------+\n | 0b0111 | Uncommon block size minus 1, stored as a |\n | | 16-bit number |\n +-----------------+---------------------------------------------+\n | 0b1000 - 0b1111 | 2^v, i.e., 256, 512, 1024, 2048, 4096, |\n | | 8192, 16384, or 32768 |\n +-----------------+---------------------------------------------+\n\n Table 14", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "9.1.2. Sample Rate Bits", + "section_title": true, + "ja": "9.1.2. サンプルレートビット" + }, + { + "indent": 3, + "text": "The next 4 bits (the last 4 bits of the third byte of each frame), referred to as the sample rate bits, contain the sample rate of the audio according to the following table. If the sample rate bits code for an uncommon sample rate, this is stored after the uncommon block size; if no uncommon block size was used, this is stored after the coded number. See Section 9.1.7.", + "ja": "サンプルレートビットと呼ばれる次の4ビット（各フレームの3番目のバイトの最後の4ビット）には、次の表に従ってオーディオのサンプルレートが含まれています。If the sample rate bits code for an uncommon sample rate, this is stored after the uncommon block size;if no uncommon block size was used, this is stored after the coded number.See Section 9.1.7." + }, + { + "indent": 0, + "text": "+========+==========================================================+\n| Value | Sample Rate |\n+========+==========================================================+\n| 0b0000 | Sample rate only stored in the |\n| | streaminfo metadata block |\n+--------+----------------------------------------------------------+\n| 0b0001 | 88.2 kHz |\n+--------+----------------------------------------------------------+\n| 0b0010 | 176.4 kHz |\n+--------+----------------------------------------------------------+\n| 0b0011 | 192 kHz |\n+--------+----------------------------------------------------------+\n| 0b0100 | 8 kHz |\n+--------+----------------------------------------------------------+\n| 0b0101 | 16 kHz |\n+--------+----------------------------------------------------------+\n| 0b0110 | 22.05 kHz |\n+--------+----------------------------------------------------------+\n| 0b0111 | 24 kHz |\n+--------+----------------------------------------------------------+\n| 0b1000 | 32 kHz |\n+--------+----------------------------------------------------------+\n| 0b1001 | 44.1 kHz |\n+--------+----------------------------------------------------------+\n| 0b1010 | 48 kHz |\n+--------+----------------------------------------------------------+\n| 0b1011 | 96 kHz |\n+--------+----------------------------------------------------------+\n| 0b1100 | Uncommon sample rate in kHz, |\n| | stored as an 8-bit number |\n+--------+----------------------------------------------------------+\n| 0b1101 | Uncommon sample rate in Hz, stored |\n| | as a 16-bit number |\n+--------+----------------------------------------------------------+\n| 0b1110 | Uncommon sample rate in Hz divided |\n| | by 10, stored as a 16-bit number |\n+--------+----------------------------------------------------------+\n| 0b1111 | Forbidden |\n+--------+----------------------------------------------------------+\n\n Table 15", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "9.1.3. Channels Bits", + "section_title": true, + "ja": "9.1.3. チャンネルビット" + }, + { + "indent": 3, + "text": "The next 4 bits (the first 4 bits of the fourth byte of each frame), referred to as the channels bits, contain both the number of channels of the audio as well as any stereo decorrelation used according to the following table.", + "ja": "次の4ビット（各フレームの4番目のバイトの最初の4ビット）は、チャンネルビットと呼ばれ、オーディオのチャネル数と、次の表に従って使用されるステレオ除去の両方を含む。" + }, + { + "indent": 3, + "text": "If a channel layout different than the ones listed in the following table is used, this can be signaled with a WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag in a Vorbis comment metadata block; see Section 8.6.2 for details. Note that even when such a different channel layout is specified with a WAVEFORMATEXTENSIBLE_CHANNEL_MASK and the channel ordering in the following table is overridden, the channels bits still contain the actual number of channels coded in the frame. For details on the way left-side, side-right, and mid-side stereo are coded, see Section 4.2.", + "ja": "次の表にリストされているものとは異なるチャネルレイアウトが使用される場合、これはVorbisコメントメタデータブロックに波形Xtensible_Channel_Maskタグで信号を送ることができます。詳細については、セクション8.6.2を参照してください。このような異なるチャネルレイアウトがWaveformatextensible_Channel_Maskで指定されている場合でも、次の表のチャネルの順序付けがオーバーライドされている場合、チャネルビットにはフレームにコードされた実際の数のチャネル数が含まれています。左サイド、サイドライト、およびミッドサイドのステレオの方法の詳細については、セクション4.2を参照してください。" + }, + { + "indent": 2, + "text": " +==========+====================================================+\n | Value | Channels |\n +==========+====================================================+\n | 0b0000 | 1 channel: mono |\n +----------+----------------------------------------------------+\n | 0b0001 | 2 channels: left, right |\n +----------+----------------------------------------------------+\n | 0b0010 | 3 channels: left, right, center |\n +----------+----------------------------------------------------+\n | 0b0011 | 4 channels: front left, front right, back left, |\n | | back right |\n +----------+----------------------------------------------------+\n | 0b0100 | 5 channels: front left, front right, front center, |\n | | back/surround left, back/surround right |\n +----------+----------------------------------------------------+\n | 0b0101 | 6 channels: front left, front right, front center, |\n | | LFE, back/surround left, back/surround right |\n +----------+----------------------------------------------------+\n | 0b0110 | 7 channels: front left, front right, front center, |\n | | LFE, back center, side left, side right |\n +----------+----------------------------------------------------+\n | 0b0111 | 8 channels: front left, front right, front center, |\n | | LFE, back left, back right, side left, side right |\n +----------+----------------------------------------------------+\n | 0b1000 | 2 channels: left, right; stored as left-side |\n | | stereo |\n +----------+----------------------------------------------------+\n | 0b1001 | 2 channels: left, right; stored as side-right |\n | | stereo |\n +----------+----------------------------------------------------+\n | 0b1010 | 2 channels: left, right; stored as mid-side stereo |\n +----------+----------------------------------------------------+\n | 0b1011 - | Reserved |\n | 0b1111 | |\n +----------+----------------------------------------------------+\n\n Table 16", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "9.1.4. Bit Depth Bits", + "section_title": true, + "ja": "9.1.4. ビット深度ビット" + }, + { + "indent": 3, + "text": "The next 3 bits (bits 5, 6, and 7 of each fourth byte of each frame) contain the bit depth of the audio according to the following table. The next bit is reserved and MUST be zero.", + "ja": "次の3ビット（各フレームの各4バイトのビット5、6、および7）には、次の表に従ってオーディオのビット深さが含まれています。次のビットは予約されており、ゼロでなければなりません。" + }, + { + "indent": 1, + "text": " +=======+========================================================+\n | Value | Bit Depth |\n +=======+========================================================+\n | 0b000 | Bit depth only stored in the streaminfo metadata block |\n +-------+--------------------------------------------------------+\n | 0b001 | 8 bits per sample |\n +-------+--------------------------------------------------------+\n | 0b010 | 12 bits per sample |\n +-------+--------------------------------------------------------+\n | 0b011 | Reserved |\n +-------+--------------------------------------------------------+\n | 0b100 | 16 bits per sample |\n +-------+--------------------------------------------------------+\n | 0b101 | 20 bits per sample |\n +-------+--------------------------------------------------------+\n | 0b110 | 24 bits per sample |\n +-------+--------------------------------------------------------+\n | 0b111 | 32 bits per sample |\n +-------+--------------------------------------------------------+\n\n Table 17", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "9.1.5. Coded Number", + "section_title": true, + "ja": "9.1.5. コード化された番号" + }, + { + "indent": 3, + "text": "Following the reserved bit (starting at the fifth byte of the frame) is either a sample or a frame number, which will be referred to as the coded number. When dealing with variable block size streams, the sample number of the first sample in the frame is encoded. When the file contains a fixed block size stream, the frame number is encoded. See Section 9.1 on the blocking strategy bit, which signals whether a stream is a fixed block size stream or a variable block size stream. See also Appendix B.1.", + "ja": "予約されたビット（フレームの5番目のバイトから始まる）に続くのは、サンプルまたはフレーム番号のいずれかで、コード化された番号と呼ばれます。可変ブロックサイズのストリームを扱うとき、フレーム内の最初のサンプルのサンプル番号がエンコードされます。ファイルに固定ブロックサイズのストリームが含まれている場合、フレーム番号がエンコードされます。ブロッキング戦略ビットのセクション9.1を参照してください。これは、ストリームが固定ブロックサイズのストリームであるか、可変ブロックサイズのストリームであるかを示すものです。付録B.1も参照してください。" + }, + { + "indent": 3, + "text": "The coded number is stored in a variable-length code like UTF-8 as defined in [RFC3629] but extended to a maximum of 36 bits unencoded or 7 bytes encoded.", + "ja": "コード化された数値は、[RFC3629]で定義されているようにUTF-8のような可変長コードに保存されますが、エンコードされていない最大36ビットまたはエンコードされた7バイトに拡張されます。" + }, + { + "indent": 3, + "text": "When a frame number is encoded, the value MUST NOT be larger than what fits a value of 31 bits unencoded or 6 bytes encoded. Please note that as most general purpose UTF-8 encoders and decoders follow [RFC3629], they will not be able to handle these extended codes. Furthermore, while UTF-8 is specifically used to encode characters, FLAC uses it to encode numbers instead. To encode or decode a coded number, follow the procedures in Section 3 of [RFC3629], but instead of using a character number, use a frame or sample number. In addition, use the extended table below instead of the table in Section 3 of [RFC3629].", + "ja": "フレーム番号がエンコードされている場合、値は、エンコードされていない31ビットまたはエンコードされた6バイトの値よりも大きくてはなりません。ほとんどの汎用目的UTF-8エンコーダーとデコーダーが続くため[RFC3629]、これらの拡張コードを処理できないことに注意してください。さらに、UTF-8は特に文字をエンコードするために使用されますが、FLACは代わりに数値をエンコードするために使用します。コード化された番号をエンコードまたはデコードするには、[RFC3629]のセクション3の手順に従ってください。ただし、文字番号を使用する代わりに、フレームまたはサンプル番号を使用します。さらに、[RFC3629]のセクション3の表の代わりに、下の拡張テーブルを使用します。" + }, + { + "indent": 0, + "text": "+============================+=====================================+\n| Number Range (Hexadecimal) | Octet Sequence (Binary) |\n+============================+=====================================+\n| 0000 0000 0000 - | 0xxxxxxx |\n| 0000 0000 007F | |\n+----------------------------+-------------------------------------+\n| 0000 0000 0080 - | 110xxxxx 10xxxxxx |\n| 0000 0000 07FF | |\n+----------------------------+-------------------------------------+\n| 0000 0000 0800 - | 1110xxxx 10xxxxxx 10xxxxxx |\n| 0000 0000 FFFF | |\n+----------------------------+-------------------------------------+\n| 0000 0001 0000 - | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx |\n| 0000 001F FFFF | |\n+----------------------------+-------------------------------------+\n| 0000 0020 0000 - | 111110xx 10xxxxxx 10xxxxxx 10xxxxxx |\n| 0000 03FF FFFF | 10xxxxxx |\n+----------------------------+-------------------------------------+\n| 0000 0400 0000 - | 1111110x 10xxxxxx 10xxxxxx 10xxxxxx |\n| 0000 7FFF FFFF | 10xxxxxx 10xxxxxx |\n+----------------------------+-------------------------------------+\n| 0000 8000 0000 - | 11111110 10xxxxxx 10xxxxxx 10xxxxxx |\n| 000F FFFF FFFF | 10xxxxxx 10xxxxxx 10xxxxxx |\n+----------------------------+-------------------------------------+\n\n Table 18", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "If the coded number is a frame number, it MUST be equal to the number of frames preceding the current frame. If the coded number is a sample number, it MUST be equal to the number of samples preceding the current frame. In a stream where these requirements are not met, seeking is not (reliably) possible.", + "ja": "コード化された番号がフレーム番号の場合、現在のフレームの前のフレームの数に等しくなければなりません。コード化された数値がサンプル番号の場合、現在のフレームの前のサンプルの数に等しくなければなりません。これらの要件が満たされないストリームでは、求めることは（確実に）不可能です。" + }, + { + "indent": 3, + "text": "For example, for a frame that belongs to a variable block size stream and has exactly 51 billion samples preceding it, the coded number is constructed as follows:", + "ja": "たとえば、可変ブロックサイズのストリームに属し、その先に510億のサンプルがあるフレームの場合、コード化された数値は次のように構築されます。" + }, + { + "indent": 3, + "text": "Octets 1-5\n0b11111110 0b10101111 0b10011111 0b10110101 0b10100011\n ^^^^^^ ^^^^^^ ^^^^^^ ^^^^^^\n | | | Bits 18-13\n | | Bits 24-19\n | Bits 30-25\n Bits 36-31\n\nOctets 6-7\n0b10111000 0b10000000\n ^^^^^^ ^^^^^^\n | Bits 6-1\n Bits 12-7", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "A decoder that relies on the coded number during seeking could be vulnerable to buffer overflows or getting stuck in an infinite loop if it seeks in a stream where the coded numbers are not strictly increasing or are otherwise not valid. See also Section 11.", + "ja": "シーク中にコード化された数値に依存するデコーダーは、コード化された数値が厳密に増加していないか、そうでなければ有効でないストリームで探す場合、バッファーオーバーフローや無限のループに詰まっていることに対して脆弱である可能性があります。セクション11も参照してください。" + }, + { + "indent": 0, + "text": "9.1.6. Uncommon Block Size", + "section_title": true, + "ja": "9.1.6. まれなブロックサイズ" + }, + { + "indent": 3, + "text": "If the block size bits defined earlier in this section are 0b0110 or 0b0111 (uncommon block size minus 1 stored), the block size minus 1 follows the coded number as either an 8-bit or 16-bit unsigned number coded big-endian. A value of 65535 (corresponding to a block size of 65536) is forbidden and MUST NOT be used, because such a block size cannot be represented in the streaminfo metadata block. A value from 0 up to (and including) 14, which corresponds to a block size from 1 to 15, is only valid for the last frame in a stream and MUST NOT be used for any other frame. See also Section 8.2.", + "ja": "このセクションの前半に定義されたブロックサイズビットが0B0110または0B0111（除外されていない未知のブロックサイズマイナス1保存）の場合、ブロックサイズマイナス1は、コード化された数を8ビットまたは16ビットの符号なしの数字コード化されたビッグエンディアンとして追跡します。65535の値（65536のブロックサイズに対応）は禁止されており、そのようなブロックサイズをStreaminfoメタデータブロックで表すことができないため、使用してはなりません。1から15までのブロックサイズに対応する0から（および含む）14から14までの値は、ストリーム内の最後のフレームに対してのみ有効であり、他のフレームには使用してはなりません。セクション8.2も参照してください。" + }, + { + "indent": 0, + "text": "9.1.7. Uncommon Sample Rate", + "section_title": true, + "ja": "9.1.7. まれなサンプルレート" + }, + { + "indent": 3, + "text": "If the sample rate bits are 0b1100, 0b1101, or 0b1110 (uncommon sample rate stored), the sample rate follows the uncommon block size (or the coded number if no uncommon block size is stored) as either an 8-bit or a 16-bit unsigned number coded big-endian.", + "ja": "サンプルレートビットが0B1100、0B1101、または0B1110（サンプルレートを格納していない）の場合、サンプルレートは、8ビットまたは16-のいずれかとして、CONCOMMONブロックサイズがない場合はコード化された数値を使用していない場合）に従います。ビット署名数字コード化されたビッグエンディアン。" + }, + { + "indent": 3, + "text": "The sample rate MUST NOT be 0 when the subframe contains audio. A sample rate of 0 MAY be used when non-audio is represented. See Section 8.2 for details.", + "ja": "サブフレームにオーディオが含まれている場合、サンプルレートは0ではありません。非オーディオが表される場合、0のサンプルレートを使用できます。詳細については、セクション8.2を参照してください。" + }, + { + "indent": 0, + "text": "9.1.8. Frame Header CRC", + "section_title": true, + "ja": "9.1.8. フレームヘッダーCRC" + }, + { + "indent": 3, + "text": "Finally, an 8-bit CRC follows the frame/sample number, an uncommon block size, or an uncommon sample rate (depending on whether the latter two are stored). This CRC is initialized with 0 and has the polynomial x^8 + x^2 + x^1 + x^0. This CRC covers the whole frame header before the CRC, including the sync code.", + "ja": "最後に、8ビットCRCは、フレーム/サンプル番号、珍しいブロックサイズ、または珍しいサンプルレートに従います（後者の2つが保存されているかどうかに応じて）。このCRCは0で初期化され、多項式x^8 + x^2 + x^1 + x^0があります。このCRCは、同期コードを含むCRCの前にフレームヘッダー全体をカバーします。" + }, + { + "indent": 0, + "text": "9.2. Subframes", + "section_title": true, + "ja": "9.2. サブフレーム" + }, + { + "indent": 3, + "text": "Following the frame header are a number of subframes equal to the number of audio channels. Note that subframes contain a bitstream that does not necessarily have to be a whole number of bytes, so only the first subframe starts at a byte boundary.", + "ja": "フレームヘッダーに従うことは、オーディオチャネルの数に等しい多数のサブフレームがあります。サブフレームには、必ずしもすべてのバイトである必要はないビットストリームが含まれているため、最初のサブフレームのみがバイト境界で始まることに注意してください。" + }, + { + "indent": 0, + "text": "9.2.1. Subframe Header", + "section_title": true, + "ja": "9.2.1. サブフレームヘッダー" + }, + { + "indent": 3, + "text": "Each subframe starts with a header. The first bit of the header MUST be 0, followed by 6 bits that describe which subframe type is used according to the following table, where v is the value of the 6 bits as an unsigned number.", + "ja": "各サブフレームはヘッダーから始まります。ヘッダーの最初のビットは0でなければなりません。その後、次の表に従って使用されるサブフレームタイプを説明する6ビットが続きます。ここで、vは6ビットの値が符号なし数として値です。" + }, + { + "indent": 1, + "text": " +=====================+===========================================+\n | Value | Subframe Type |\n +=====================+===========================================+\n | 0b000000 | Constant subframe |\n +---------------------+-------------------------------------------+\n | 0b000001 | Verbatim subframe |\n +---------------------+-------------------------------------------+\n | 0b000010 - 0b000111 | Reserved |\n +---------------------+-------------------------------------------+\n | 0b001000 - 0b001100 | Subframe with a fixed predictor of order |\n | | v-8; i.e., 0, 1, 2, 3 or 4 |\n +---------------------+-------------------------------------------+\n | 0b001101 - 0b011111 | Reserved |\n +---------------------+-------------------------------------------+\n | 0b100000 - 0b111111 | Subframe with a linear predictor of order |\n | | v-31; i.e., 1 through 32 (inclusive) |\n +---------------------+-------------------------------------------+\n\n Table 19", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Following the subframe type bits is a bit that flags whether the subframe uses any wasted bits (see Section 9.2.2). If the flag bit is 0, the subframe doesn't use any wasted bits and the subframe header is complete. If the flag bit is 1, the subframe uses wasted bits and the number of used wasted bits minus 1 appears in unary form, directly following the flag bit.", + "ja": "サブフレームタイプのビットに従うことは、サブフレームが無駄なビットを使用するかどうかにフラグを立てることに少しです（セクション9.2.2を参照）。フラグビットが0の場合、サブフレームは無駄なビットを使用せず、サブフレームヘッダーが完了します。フラグビットが1の場合、サブフレームは無駄なビットを使用し、使用済みビットマイナス1の数は、フラグビットに直接続く統一形式で表示されます。" + }, + { + "indent": 0, + "text": "9.2.2. Wasted Bits per Sample", + "section_title": true, + "ja": "9.2.2. サンプルごとに無駄なビット" + }, + { + "indent": 3, + "text": "Most uncompressed audio file formats can only store audio samples with a bit depth that is an integer number of bytes. Samples in which the bit depth is not an integer number of bytes are usually stored in such formats by padding them with least-significant zero bits to a bit depth that is an integer number of bytes. For example, shifting a 14-bit sample right by 2 pads it to a 16-bit sample, which then has two zero least-significant bits. In this specification, these least-significant zero bits are referred to as wasted bits per sample or simply wasted bits. They are wasted in the sense that they contain no information but are stored anyway.", + "ja": "ほとんどの非圧縮オーディオファイル形式は、整数のバイト数である少し深さでオーディオサンプルのみを保存できます。ビット深度が整数数のバイト数ではないサンプルは、通常、整数ゼロビットで整数の深さであるバイト数であるビット深度にパディングすることにより、そのような形式で保存されます。たとえば、14ビットのサンプルを2倍にシフトすると、16ビットのサンプルにパッドを配置し、2つの最小重要なビットがあります。この仕様では、これらの最も重要でないゼロビットは、サンプルごとに無駄なビットまたは単に無駄なビットと呼ばれます。彼らは情報を含んでいないがとにかく保存されているという意味で無駄になります。" + }, + { + "indent": 3, + "text": "The FLAC format can optionally take advantage of these wasted bits by signaling their presence and coding the subframe without them. To do this, the wasted bits per sample flag in a subframe header is set to 1 and the number of wasted bits per sample (k) minus 1 follows the flag in an unary encoding. For example, if k is 3, 0b001 follows. If k = 0, the wasted bits per sample flag is 0 and no unary-coded k follows. In this document, if a subframe header signals a certain number of wasted bits, it is said it \"uses\" these wasted bits.", + "ja": "FLAC形式は、オプションでこれらの無駄なビットを利用して、それらの存在を通知し、サブフレームを使用せずにコーディングすることにより、これらの無駄なビットを利用できます。これを行うために、サブフレームヘッダーのサンプルフラグごとの無駄なビットは1に設定され、サンプルあたりの無駄なビット数（k）マイナス1は、単位エンコードでフラグに続きます。たとえば、Kが3の場合、0B001が続きます。k = 0の場合、サンプルフラグごとに無駄なビットが0であり、unary-coded kは続きません。このドキュメントでは、サブフレームヘッダーが一定数の無駄なビットを信号する場合、これらの無駄なビットを「使用」すると言われています。" + }, + { + "indent": 3, + "text": "If a subframe uses wasted bits (i.e., k is not equal to 0), samples are coded ignoring k least-significant bits. For example, if a frame not employing stereo decorrelation specifies a sample size of 16 bits per sample in the frame header and k of a subframe is 3, samples in the subframe are coded as 13 bits per sample. For more details, see Section 9.2.3 on how the bit depth of a subframe is calculated. A decoder MUST add k least-significant zero bits by shifting left (padding) after decoding a subframe sample. If the frame has left-side, side-right, or mid-side stereo, a decoder MUST perform padding on the subframes before restoring the channels to left and right. The number of wasted bits per sample MUST be such that the resulting number of bits per sample (of which the calculation is explained in Section 9.2.3) is larger than zero.", + "ja": "サブフレームが無駄なビットを使用している場合（つまり、Kは0に等しくない）、サンプルはKの最も重要なビットを無視してコード化されます。たとえば、ステレオ脱線を使用していないフレームがフレームヘッダーのサンプルあたり16ビットのサンプルサイズを指定し、サブフレームのKのKが3の場合、サブフレームのサンプルはサンプルごとに13ビットとしてコーディングされます。詳細については、サブフレームのビット深さの計算方法については、セクション9.2.3を参照してください。デコーダーは、サブフレームサンプルをデコードした後、左（パディング）をシフトすることにより、Kの最小重要なゼロビットを追加する必要があります。フレームに左側、側面、または中央のステレオがある場合、デコーダーはチャネルを左右に復元する前にサブフレームでパディングを実行する必要があります。サンプルあたりの無駄なビット数は、サンプルあたりのビット数（セクション9.2.3で説明されている）がゼロよりも大きいようにする必要があります。" + }, + { + "indent": 3, + "text": "Besides audio files that have a certain number of wasted bits for the whole file, audio files exist in which the number of wasted bits varies. There are DVD-Audio discs in which blocks of samples have had their least-significant bits selectively zeroed to slightly improve the compression of their otherwise lossless Meridian Lossless Packing codec; see [MLP]. There are also audio processors like lossyWAV (see [lossyWAV]) that zero a number of least-significant bits for a block of samples, increasing the compression in a non-lossless way. Because of this, the number of wasted bits k MAY change between frames and MAY differ between subframes. If the number of wasted bits changes halfway through a subframe (e.g., the first part has 2 wasted bits and the second part has 4 wasted bits), the subframe uses the lowest number of wasted bits; otherwise, non-zero bits would be discarded, and the process would not be lossless.", + "ja": "ファイル全体に一定数の無駄なビットを持つオーディオファイルに加えて、無駄なビットの数が異なるオーディオファイルが存在します。サンプルのブロックが最も重要でないビットを選択的にゼロにして、それ以外の場合は損失のない子午線ロスレスパッキングコーデックの圧縮をわずかに改善するDVD-Audioディスクがあります。[MLP]を参照してください。また、サンプルのブロックで最も重要な少ないビットをゼロでゼロで、損失のない方法で圧縮を増加させる、losywav（[losywav]を参照）などのオーディオプロセッサもあります。このため、無駄なビットkの数はフレーム間で変化し、サブフレーム間で異なる場合があります。無駄なビットの数がサブフレームの途中で変化する場合（たとえば、最初の部分には2つの無駄なビットがあり、2番目の部分には4つのビットが4つあります）、サブフレームは無駄なビットの数が最も少ないです。そうしないと、ゼロ以外のビットが破棄され、プロセスはロスレスになりません。" + }, + { + "indent": 0, + "text": "9.2.3. Constant Subframe", + "section_title": true, + "ja": "9.2.3. 定数サブフレーム" + }, + { + "indent": 3, + "text": "In a constant subframe, only a single sample is stored. This sample is stored as an integer number coded big-endian, signed two's complement. The number of bits used to store this sample depends on the bit depth of the current subframe. The bit depth of a subframe is equal to the bit depth as coded in the frame header (see Section 9.1.4) minus the number of used wasted bits coded in the subframe header (see Section 9.2.2). If a subframe is a side subframe (see Section 4.2), the bit depth of that subframe is increased by 1 bit.", + "ja": "一定のサブフレームでは、1つのサンプルのみが保存されます。このサンプルは、ビッグエンディアンのコード化された整数番号として保存され、2人の補完に署名されています。このサンプルを保存するために使用されるビットの数は、現在のサブフレームのビット深度に依存します。サブフレームのビット深度は、フレームヘッダーでコード化されたビット深度に等しくなります（セクション9.1.4を参照）は、サブフレームヘッダーでコード化された使用された無駄なビットの数を差し引いて（セクション9.2.2を参照）。サブフレームがサイドサブフレームである場合（セクション4.2を参照）、そのサブフレームのビット深度は1ビット増加します。" + }, + { + "indent": 0, + "text": "9.2.4. Verbatim Subframe", + "section_title": true, + "ja": "9.2.4. Verbatimサブフレーム" + }, + { + "indent": 3, + "text": "A verbatim subframe stores all samples unencoded in sequential order. See Section 9.2.3 on how a sample is stored unencoded. The number of samples that need to be stored in a subframe is provided by the block size in the frame header.", + "ja": "逐語的なサブフレームは、順次順序でエンコードされていないすべてのサンプルを保存します。サンプルがエンコードされていない保管方法については、セクション9.2.3を参照してください。サブフレームに保存する必要があるサンプルの数は、フレームヘッダーのブロックサイズによって提供されます。" + }, + { + "indent": 0, + "text": "9.2.5. Fixed Predictor Subframe", + "section_title": true, + "ja": "9.2.5. 予測子サブフレームを修正しました" + }, + { + "indent": 3, + "text": "Five different fixed predictors are defined in the following table, one for each prediction order 0 through 4. The table also contains a derivation that explains the rationale for choosing these fixed predictors.", + "ja": "次の表には、5つの異なる固定予測子が定義されています。1つは予測順序0〜4です。表には、これらの固定予測因子を選択する理論的根拠を説明する派生も含まれています。" + }, + { + "indent": 1, + "text": " +=======+==================================+======================+\n | Order | Prediction | Derivation |\n +=======+==================================+======================+\n | 0 | 0 | N/A |\n +-------+----------------------------------+----------------------+\n | 1 | a(n-1) | N/A |\n +-------+----------------------------------+----------------------+\n | 2 | 2 * a(n-1) - a(n-2) | a(n-1) + a'(n-1) |\n +-------+----------------------------------+----------------------+\n | 3 | 3 * a(n-1) - 3 * a(n-2) + a(n-3) | a(n-1) + a'(n-1) + |\n | | | a''(n-1) |\n +-------+----------------------------------+----------------------+\n | 4 | 4 * a(n-1) - 6 * a(n-2) + 4 * | a(n-1) + a'(n-1) + |\n | | a(n-3) - a(n-4) | a''(n-1) + a'''(n-1) |\n +-------+----------------------------------+----------------------+\n\n Table 20", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Where:", + "ja": "ただし：" + }, + { + "indent": 6, + "text": "* n is the number of the sample being predicted.", + "ja": "* nは予測されるサンプルの数です。" + }, + { + "indent": 6, + "text": "* a(n) is the sample being predicted.", + "ja": "* A（n）は予測されるサンプルです。" + }, + { + "indent": 6, + "text": "* a(n-1) is the sample before the one being predicted.", + "ja": "* A（n-1）は、予測される前のサンプルです。" + }, + { + "indent": 6, + "text": "* a'(n-1) is the difference between the previous sample and the sample before that, i.e., a(n-1) - a(n-2). This is the closest available first-order discrete derivative.", + "ja": "* a '（n-1）は、前のサンプルとその前のサンプルの違い、すなわちa（n-1）-a（n-2）です。これは、最も近い1次離散微分です。" + }, + { + "indent": 6, + "text": "* a''(n-1) is a'(n-1) - a'(n-2) or the closest available second-order discrete derivative.", + "ja": "* a ''（n-1）はa '（n-1） - a'（n-2）または最も近い2次離散微分です。" + }, + { + "indent": 6, + "text": "* a'''(n-1) is a''(n-1) - a''(n-2) or the closest available third-order discrete derivative.", + "ja": "* a '' '（n-1）はa' '（n-1）-a' '（n-2）または最も近い3次離散微分です。" + }, + { + "indent": 3, + "text": "As a predictor makes use of samples preceding the sample that is predicted, it can only be used when enough samples are known. As each subframe in FLAC is coded completely independently, the first few samples in each subframe cannot be predicted. Therefore, a number of so-called warm-up samples equal to the predictor order is stored. These are stored unencoded, bypassing the predictor and residual coding stages. See Section 9.2.3 on how samples are stored unencoded. The table below defines how a fixed predictor subframe appears in the bitstream.", + "ja": "予測子は、予測されるサンプルの前のサンプルを使用するため、十分なサンプルがわかっている場合にのみ使用できます。FLACの各サブフレームは完全に独立してコーディングされるため、各サブフレームの最初の数サンプルは予測できません。したがって、予測順に等しいいわゆるウォームアップサンプルが保存されます。これらは、予測因子と残留コーディング段階をバイパスして、エンコードされていない保存されます。サンプルがエンコードされていない保管方法については、セクション9.2.3を参照してください。以下の表は、BitStreamに固定予測サブフレームがどのように表示されるかを定義しています。" + }, + { + "indent": 6, + "text": " +==========+===========================================+\n | Data | Description |\n +==========+===========================================+\n | s(n) | Unencoded warm-up samples (n = subframe's |\n | | bits per sample * predictor order). |\n +----------+-------------------------------------------+\n | Coded | Coded residual as defined in |\n | residual | Section 9.2.7 |\n +----------+-------------------------------------------+\n\n Table 21", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Because fixed predictors are specified, they do not have to be stored. The fixed predictor order, which is stored in the subframe header, specifies which predictor is used.", + "ja": "固定予測子が指定されているため、保存する必要はありません。サブフレームヘッダーに保存されている固定予測順序は、どの予測子が使用されるかを指定します。" + }, + { + "indent": 3, + "text": "To encode a signal with a fixed predictor, each sample has the corresponding prediction subtracted and sent to the residual coder. To decode a signal with a fixed predictor, the residual is decoded, and then the prediction can be added for each sample. This means that decoding is necessarily a sequential process within a subframe, as for each sample, enough fully decoded previous samples are needed to calculate the prediction.", + "ja": "固定予測子を使用して信号をエンコードするために、各サンプルには対応する予測が差し引かれ、残差コーダーに送信されます。固定予測子で信号をデコードするために、残差がデコードされ、各サンプルに予測を追加できます。つまり、デコードは必然的にサブフレーム内の連続プロセスであり、各サンプルと同様に、予測を計算するのに十分な完全にデコードされた以前のサンプルが必要であることを意味します。" + }, + { + "indent": 3, + "text": "For fixed predictor order 0, the prediction is always 0; thus, each residual sample is equal to its corresponding input or decoded sample. The difference between a fixed predictor with order 0 and a verbatim subframe is that a verbatim subframe stores all samples unencoded while a fixed predictor with order 0 has all its samples processed by the residual coder.", + "ja": "固定された予測因子順序0の場合、予測は常に0です。したがって、各残差サンプルは、対応する入力またはデコードされたサンプルに等しくなります。順序0の固定予測子と逐語的なサブフレームの違いは、逐語的なサブフレームがすべてのサンプルをエンコードされていないすべてのサンプルを保存し、注文0の固定予測子にはすべてのサンプルが残差コーダーによって処理されていることです。" + }, + { + "indent": 3, + "text": "The first-order fixed predictor is comparable to how differential pulse-code modulation (DPCM) encoding works, as the resulting residual sample is the difference between the corresponding sample and the sample before it. The higher-order fixed predictors can be understood as polynomials fitted to the previous samples.", + "ja": "一次固定予測子は、結果の残差サンプルが対応するサンプルとその前のサンプルの違いであるため、微分パルスコード変調（DPCM）エンコーディングがどのように機能するかに匹敵します。高次の固定予測因子は、以前のサンプルに適合した多項式として理解できます。" + }, + { + "indent": 0, + "text": "9.2.6. Linear Predictor Subframe", + "section_title": true, + "ja": "9.2.6. 線形予測サブフレーム" + }, + { + "indent": 3, + "text": "Whereas fixed predictors are well suited for simple signals, using a (non-fixed) linear predictor on more complex signals can improve compression by making the residual samples even smaller. There is a certain trade-off, however, as storing the predictor coefficients takes up space as well.", + "ja": "一方、固定された予測因子は単純な信号に適していますが、より複雑な信号に（固定されていない）線形予測因子を使用すると、残差サンプルをさらに小さくすることで圧縮を改善できます。ただし、予測係数を保存することもスペースを占めるため、特定のトレードオフがあります。" + }, + { + "indent": 3, + "text": "In the FLAC format, a predictor is defined by up to 32 predictor coefficients and a shift. To form a prediction, each coefficient is multiplied by its corresponding past sample, the results are summed, and this sum is then shifted. To encode a signal with a linear predictor, each sample has the corresponding prediction subtracted and sent to the residual coder. To decode a signal with a linear predictor, the residual is decoded, and then the prediction can be added for each sample. This means that decoding MUST be a sequential process within a subframe, as enough decoded samples are needed to calculate the prediction for each sample.", + "ja": "FLAC形式では、予測子は最大32の予測係数とシフトによって定義されます。予測を形成するために、各係数に対応する過去のサンプルを掛け、結果が合計され、この合計がシフトされます。線形予測子を使用して信号をエンコードするために、各サンプルには対応する予測が減算され、残差コーダーに送信されます。線形予測因子で信号をデコードするために、残差がデコードされ、各サンプルに予測を追加できます。つまり、各サンプルの予測を計算するのに十分なデコードされたサンプルが必要であるため、デコードはサブフレーム内の順次プロセスでなければなりません。" + }, + { + "indent": 3, + "text": "The table below defines how a linear predictor subframe appears in the bitstream.", + "ja": "以下の表は、ビットストリームに線形予測サブフレームがどのように表示されるかを定義しています。" + }, + { + "indent": 7, + "text": " +==========+==========================================+\n | Data | Description |\n +==========+==========================================+\n | s(n) | Unencoded warm-up samples (n = |\n | | subframe's bits per sample * LPC order). |\n +----------+------------------------------------------+\n | u(4) | (Predictor coefficient precision in |\n | | bits)-1 (Note: 0b1111 is forbidden). |\n +----------+------------------------------------------+\n | s(5) | Prediction right shift needed in bits. |\n +----------+------------------------------------------+\n | s(n) | Predictor coefficients (n = predictor |\n | | coefficient precision * LPC order). |\n +----------+------------------------------------------+\n | Coded | Coded residual as defined in |\n | residual | Section 9.2.7. |\n +----------+------------------------------------------+\n\n Table 22", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "See Section 9.2.3 on how the warm-up samples are stored unencoded. The predictor coefficients are stored as an integer number coded big-endian, signed two's complement, where the number of bits needed for each coefficient is defined by the predictor coefficient precision. While the prediction right shift is signed two's complement, this number MUST NOT be negative; see Appendix B.4 for an explanation why this is.", + "ja": "ウォームアップサンプルがエンコードされていない保管方法については、セクション9.2.3を参照してください。予測係数は、各係数に必要なビット数が予測係数精度によって定義される2つの補数に署名された2つの補数に署名された整数の補体された整数数として保存されます。予測の正しいシフトはTwoの補完に署名されていますが、この数は否定的であってはなりません。これがなぜであるかについては、付録B.4を参照してください。" + }, + { + "indent": 3, + "text": "Please note that the order in which the predictor coefficients appear in the bitstream corresponds to which *past* sample they belong to. In other words, the order of the predictor coefficients is opposite to the chronological order of the samples. So, the first predictor coefficient has to be multiplied with the sample directly before the sample that is being predicted, the second predictor coefficient has to be multiplied with the sample before that, etc.", + "ja": "ビットストリームに予測係数が表示される順序は、それらが属している *過去 *サンプルに対応することに注意してください。言い換えれば、予測係数の順序は、サンプルの時系列の順序とは反対です。したがって、最初の予測係数は、予測されるサンプルの直前にサンプルとの直前に、2番目の予測係数をその前にサンプルに乗算する必要があります。" + }, + { + "indent": 0, + "text": "9.2.7. Coded Residual", + "section_title": true, + "ja": "9.2.7. コード化された残差" + }, + { + "indent": 3, + "text": "The first two bits in a coded residual indicate which coding method is used. See the table below.", + "ja": "コード化された残差の最初の2つのビットは、どのコーディング方法が使用されているかを示します。以下の表を参照してください。" + }, + { + "indent": 4, + "text": " +=============+=============================================+\n | Value | Description |\n +=============+=============================================+\n | 0b00 | Partitioned Rice code with 4-bit parameters |\n +-------------+---------------------------------------------+\n | 0b01 | Partitioned Rice code with 5-bit parameters |\n +-------------+---------------------------------------------+\n | 0b10 - 0b11 | Reserved |\n +-------------+---------------------------------------------+\n\n Table 23", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Both defined coding methods work the same way but differ in the number of bits used for Rice parameters. The 4 bits that directly follow the coding method bits form the partition order, which is an unsigned number. The rest of the coded residual consists of 2^(partition order) partitions. For example, if the 4 bits are 0b1000, the partition order is 8, and the residual is split up into 2^8 = 256 partitions.", + "ja": "両方の定義されたコーディングメソッドは同じように機能しますが、イネパラメーターに使用されるビットの数が異なります。コーディングメソッドビットに直接続く4ビットは、パーティション順序を形成します。これは署名されていない数字です。コード化された残りの残りの部分は、2^（パーティションの順序）パーティションで構成されています。たとえば、4ビットが0B1000の場合、パーティション順序は8で、残差は2^8 = 256パーティションに分割されます。" + }, + { + "indent": 3, + "text": "Each partition contains a certain number of residual samples. The number of residual samples in the first partition is equal to (block size >> partition order) - predictor order, i.e., the block size divided by the number of partitions minus the predictor order. In all other partitions, the number of residual samples is equal to (block size >> partition order).", + "ja": "各パーティションには、一定数の残差サンプルが含まれています。最初のパーティションの残差サンプルの数は、（ブロックサイズ>>パーティション順序） - 予測順、つまり、ブロックサイズをパーティションの数を差し引いて予測順に除算します。他のすべてのパーティションでは、残差サンプルの数は（ブロックサイズ>>パーティション順序）に等しくなります。" + }, + { + "indent": 3, + "text": "The partition order MUST be such that the block size is evenly divisible by the number of partitions. This means, for example, that only partition order 0 is allowed for all odd block sizes. The partition order also MUST be such that the (block size >> partition order) is larger than the predictor order. This means, for example, that with a block size of 4096 and a predictor order of 4, the partition order cannot be larger than 9.", + "ja": "パーティションの順序は、ブロックサイズがパーティションの数によって均等に分裂できるようにする必要があります。これは、たとえば、すべての奇数ブロックサイズでパーティション順序0のみが許可されることを意味します。パーティション順序は、（ブロックサイズ>>パーティション順序）が予測順に大きくなるようなものでなければなりません。これは、たとえば、ブロックサイズが4096で、予測因子順序が4の場合、パーティションの順序が9を超えることはできないことを意味します。" + }, + { + "indent": 3, + "text": "Each partition starts with a parameter. If the coded residual of a subframe is one with 4-bit Rice parameters (see Table 23), the first 4 bits of each partition are either a Rice parameter or an escape code. These 4 bits indicate an escape code if they are 0b1111; otherwise, they contain the Rice parameter as an unsigned number. If the coded residual of the current subframe is one with 5-bit Rice parameters, the first 5 bits of each partition indicate an escape code if they are 0b11111; otherwise, they contain the Rice parameter as an unsigned number as well.", + "ja": "各パーティションはパラメーターから始まります。サブフレームのコード化された残差が4ビットライスパラメーターを持つものである場合（表23を参照）、各パーティションの最初の4ビットはイネパラメーターまたはエスケープコードのいずれかです。これらの4ビットは、0B1111の場合、エスケープコードを示します。それ以外の場合、それらは署名のない数字としてイネパラメーターを含みます。現在のサブフレームのコード化された残差が5ビットのイネパラメーターを持つものである場合、各パーティションの最初の5ビットは、0B11111の場合、エスケープコードを示します。それ以外の場合は、署名のない数字としてライスパラメーターも含まれています。" + }, + { + "indent": 0, + "text": "9.2.7.1. Escaped Partition", + "section_title": true, + "ja": "9.2.7.1. 逃げたパーティション" + }, + { + "indent": 3, + "text": "If an escape code was used, the partition does not contain a variable-length Rice-coded residual; rather, it contains a fixed-length unencoded residual. Directly following the escape code are 5 bits containing the number of bits with which each residual sample is stored, as an unsigned number. The residual samples themselves are stored signed two's complement. For example, when a partition is escaped and each residual sample is stored with 3 bits, the number -1 is represented as 0b111.", + "ja": "エスケープコードが使用された場合、パーティションには可変長のイネコードされた残差は含まれていません。むしろ、固定された長さの非エンコード残差が含まれています。エスケープコードの直後には、各残差サンプルが保存されているビット数を符号なしの数として含む5ビットがあります。残留サンプル自体には、署名された2つの補数が保存されます。たとえば、パーティションが脱出され、各残差サンプルが3ビットで保存されると、数値-1は0B111として表されます。" + }, + { + "indent": 3, + "text": "Note that it is possible that the number of bits with which each sample is stored is 0, which means that all residual samples in that partition have a value of 0 and that no bits are used to store the samples. In that case, the partition contains nothing except the escape code and 0b00000.", + "ja": "各サンプルが保存されているビット数は0である可能性があることに注意してください。つまり、そのパーティション内のすべての残差サンプルの値は0であり、サンプルの保存にビットが使用されないことを意味します。その場合、パーティションにはエスケープコードと0B00000以外は何も含まれていません。" + }, + { + "indent": 0, + "text": "9.2.7.2. Rice Code", + "section_title": true, + "ja": "9.2.7.2. 稲法" + }, + { + "indent": 3, + "text": "If a Rice parameter was provided for a certain partition, that partition contains a Rice-coded residual. The residual samples, which are signed numbers, are represented by unsigned numbers in the Rice code. For positive numbers, the representation is the number doubled. For negative numbers, the representation is the number multiplied by -2 and with 1 subtracted. This representation of signed numbers is also known as zigzag encoding. The zigzag-encoded residual is called the folded residual.", + "ja": "特定のパーティションにイネパラメーターが提供された場合、そのパーティションにはイネコードされた残差が含まれています。署名された番号である残留サンプルは、稲法に署名されていない番号で表されます。正の数の場合、表現は数が2倍になります。負の数の場合、表現は数に-2を掛け、1を引いたものです。署名された数字のこの表現は、Zigzagエンコーディングとしても知られています。ジグザグエンコード残差は、折り畳まれた残差と呼ばれます。" + }, + { + "indent": 3, + "text": "Each folded residual sample is then split into two parts, a most-significant part and a least-significant part. The Rice parameter at the start of each partition determines where that split lies: it is the number of bits in the least-significant part. Each residual sample is then stored by coding the most-significant part as unary, followed by the least-significant part as binary.", + "ja": "次に、折り畳まれた各残差サンプルは、最も重要な部分と重要な部分の2つの部分に分割されます。各パーティションの開始時のイネパラメーターは、その分割がどこにあるかを決定します。これは、最も重要でない部分のビット数です。次に、各残差サンプルは、最も重要な部分を単位としてコーディングし、続いてバイナリとして最も重要でない部分をコーディングすることにより保存されます。" + }, + { + "indent": 3, + "text": "For example, take a partition with Rice parameter 3 containing a folded residual sample with 38 as its value, which is 0b100110 in binary. The most-significant part is 0b100 (4) and is stored in unary form as 0b00001. The least-significant part is 0b110 (6) and is stored as is. The Rice code word is thus 0b00001110. The Rice code words for all residual samples in a partition are stored consecutively.", + "ja": "たとえば、バイナリの0B100110である38の折り畳まれた残差サンプルを含むイネパラメーター3のパーティションを取ります。最も重要な部分は0B100（4）であり、0B00001として単位形式で保存されます。最も重要でない部分は0B110（6）であり、そのまま保存されます。したがって、稲法の単語は0b00001110です。パーティション内のすべての残留サンプルの稲法の単語は、連続して保存されます。" + }, + { + "indent": 3, + "text": "To decode a Rice code word, zero bits must be counted until encountering a one bit, after which a number of bits given by the Rice parameter must be read. The count of zero bits is shifted left by the Rice parameter (i.e., multiplied by 2 raised to the power Rice parameter) and bitwise ORed with (i.e., added to) the read value. This is the folded residual value. An even folded residual value is shifted right 1 bit (i.e., divided by 2) to get the (unfolded) residual value. An odd folded residual value is shifted right 1 bit and then has all bits flipped (1 added to and divided by -2) to get the (unfolded) residual value, subject to negative numbers being signed two's complement on the decoding machine.", + "ja": "稲法の単語を解読するには、ゼロビットを1ビットに遭遇するまでカウントする必要があります。その後、米パラメーターで与えられる多数のビットを読み取る必要があります。ゼロビットのカウントは、ライスパラメーター（つまり、パワーライスパラメーターに上げられた2を掛けます）によって残され、読み取り値とビットワイズオレッド（つまり追加）されます。これは折りたたまれた残差値です。均一な折り畳まれた残留値は、（つまり、2で割って）右にシフトされ、（展開された）残差値を取得します。奇妙な折り畳まれた残留値は1ビット正しくシフトされ、すべてのビットが反転し（1に追加され、-2で割られます）、（展開された）残差値を取得します。" + }, + { + "indent": 3, + "text": "Appendix D shows decoding of a complete coded residual.", + "ja": "付録Dは、完全なコード化された残差のデコードを示しています。" + }, + { + "indent": 0, + "text": "9.2.7.3. Residual Sample Value Limit", + "section_title": true, + "ja": "9.2.7.3. 残留サンプル値制限" + }, + { + "indent": 3, + "text": "All residual sample values MUST be representable in the range offered by a 32-bit integer, signed one's complement. Equivalently, all residual sample values MUST fall in the range offered by a 32-bit integer signed two's complement, excluding the most negative possible value of that range. This means residual sample values MUST NOT have an absolute value equal to, or larger than, 2 to the power 31. A FLAC encoder MUST make sure of this. If a FLAC encoder is, for a certain subframe, unable to find a suitable predictor for which all residual samples fall within said range, it MUST default to writing a verbatim subframe. Appendix A explains in which circumstances residual samples are already implicitly representable in said range; thus, an additional check is not needed.", + "ja": "すべての残差サンプル値は、32ビットの整数によって提供される範囲で表現できるものでなければなりません。同等に、すべての残差サンプル値は、その範囲の最も負の可能な値を除く、32ビットの整数が署名した2つの補数に提供される範囲に収まる必要があります。これは、残留サンプル値が電力31に等しい、または2より大きい絶対値を持たないことを意味します。FLACエンコーダーはこれを確認する必要があります。FLACエンコーダーが、特定のサブフレームについて、すべての残差サンプルが上記の範囲内に該当する適切な予測因子を見つけることができない場合、逐語的なサブフレームを作成する必要があります。付録Aは、どのような状況で、残留サンプルがすでに上記の範囲で暗黙的に表現できるかを説明しています。したがって、追加のチェックは必要ありません。" + }, + { + "indent": 3, + "text": "The reason for this limit is to ensure that decoders can use 32-bit integers when processing residuals, simplifying decoding. The reason the most negative value of a 32-bit integer signed two's complement is specifically excluded is to prevent decoders from having to implement specific handling of that value, as it cannot be negated within a 32-bit signed integer, and most library routines calculating an absolute value have undefined behavior for processing that value.", + "ja": "この制限の理由は、デコーダーが残差を処理するときに32ビット整数を使用してデコードを簡素化できるようにすることです。32ビット整数の2つの補数に署名された32ビット整数の最も負の値が具体的に除外されている理由は、32ビットの署名された整数とほとんどのライブラリルーチン内で否定できないため、デコーダがその値の特定の処理を実装しないようにすることです。絶対値には、その値を処理するための未定義の動作があります。" + }, + { + "indent": 0, + "text": "9.3. Frame Footer", + "section_title": true, + "ja": "9.3. フレームフッター" + }, + { + "indent": 3, + "text": "Following the last subframe is the frame footer. If the last subframe is not byte aligned (i.e., the number of bits required to store all subframes put together is not divisible by 8), zero bits are added until byte alignment is reached. Following this is a 16-bit CRC, initialized with 0, with the polynomial x^16 + x^15 + x^2 + x^0. This CRC covers the whole frame, excluding the 16-bit CRC but including the sync code.", + "ja": "最後のサブフレームに続くのはフレームフッターです。最後のサブフレームがバイトに合わせられていない場合（つまり、すべてのサブフレームをまとめるために必要なビットの数が8で割り切れません）、バイトアライメントに達するまでゼロビットが追加されます。これに続くのは、0で初期化された16ビットCRCで、多項式x^16 + x^15 + x^2 + x^0で初期化されています。このCRCは、16ビットCRCを除くフレーム全体をカバーしますが、同期コードを含みます。" + }, + { + "indent": 0, + "text": "10. Container Mappings", + "section_title": true, + "ja": "10. コンテナマッピング" + }, + { + "indent": 3, + "text": "The FLAC format can be used without any container, as it already provides for the most basic features normally associated with a container. However, the functionality this basic container provides is rather limited, and for more advanced features (such as combining FLAC audio with video), it needs to be encapsulated by a more capable container. This presents a problem: because of these container features, the FLAC format mixes data that belongs to the encoded data (like block size and sample rate) with data that belongs to the container (like checksum and timecode). The choice was made to encapsulate FLAC frames as they are, which means some data will be duplicated and potentially deviating between the FLAC frames and the encapsulating container.", + "ja": "FLAC形式は、コンテナに通常関連付けられている最も基本的な機能を既に提供するため、コンテナなしで使用できます。ただし、この基本的なコンテナが提供する機能はかなり限られており、より高度な機能（FLACオーディオとビデオを組み合わせるなど）の場合、より有能なコンテナによってカプセル化する必要があります。これには問題があります。これらのコンテナ機能のため、FLAC形式は、エンコードされたデータ（ブロックサイズやサンプルレートなど）に属するデータとコンテナ（チェックサムやタイムコードなど）に属するデータを組み合わせます。この選択は、FLACフレームをそのままカプセル化するために行われました。つまり、一部のデータが複製され、FLACフレームとカプセル化コンテナの間で潜在的に逸脱する可能性があります。" + }, + { + "indent": 3, + "text": "As FLAC frames are completely independent of each other, container format features handling dependencies do not need to be used. For example, all FLAC frames embedded in Matroska are marked as keyframes when they are stored in a SimpleBlock, and tracks in an MP4 file containing only FLAC frames do not need a sync sample box.", + "ja": "FLACフレームは互いに完全に独立しているため、コンテナ形式の機能処理依存関係を使用する必要はありません。たとえば、Matroskaに埋め込まれたすべてのFLACフレームは、SimpleBlockに保存されているときにキーフレームとしてマークされ、FLACフレームのみを含むMP4ファイルのトラックには同期サンプルボックスが必要ありません。" + }, + { + "indent": 0, + "text": "10.1. Ogg Mapping", + "section_title": true, + "ja": "10.1. OGGマッピング" + }, + { + "indent": 3, + "text": "The Ogg container format is defined in [RFC3533]. The first packet of a logical bitstream carrying FLAC data is structured according to the following table.", + "ja": "OGGコンテナ形式は[RFC3533]で定義されています。FLACデータを運ぶ論理的なビットストリームの最初のパケットは、次の表に従って構成されています。" + }, + { + "indent": 0, + "text": "+=========+=========================================================+\n| Data | Description |\n+=========+=========================================================+\n| 5 | Bytes 0x7F 0x46 0x4C 0x41 0x43 (as also defined by |\n| bytes | [RFC5334]). |\n+---------+---------------------------------------------------------+\n| 2 | Version number of the FLAC-in-Ogg mapping. These bytes |\n| bytes | are 0x01 0x00, meaning version 1.0 of the mapping. |\n+---------+---------------------------------------------------------+\n| 2 | Number of header packets (excluding the first header |\n| bytes | packet) as an unsigned number coded big-endian. |\n+---------+---------------------------------------------------------+\n| 4 | The fLaC signature. |\n| bytes | |\n+---------+---------------------------------------------------------+\n| 4 | A metadata block header for the streaminfo metadata |\n| bytes | block. |\n+---------+---------------------------------------------------------+\n| 34 | A streaminfo metadata block. |\n| bytes | |\n+---------+---------------------------------------------------------+\n\n Table 24", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "The number of header packets MAY be 0, which means the number of packets that follow is unknown. This first packet MUST NOT share a Ogg page with any other packets. This means the first page of a logical stream of FLAC-in-Ogg is always 79 bytes.", + "ja": "ヘッダーパケットの数は0である可能性があります。つまり、続くパケットの数は不明です。この最初のパケットは、OGGページを他のパケットと共有してはなりません。これは、FLAC-IN-GGの論理ストリームの最初のページが常に79バイトであることを意味します。" + }, + { + "indent": 3, + "text": "Following the first packet are one or more header packets, each of which contains a single metadata block. The first of these packets SHOULD be a Vorbis comment metadata block for historic reasons. This is contrary to unencapsulated FLAC streams, where the order of metadata blocks is not important except for the streaminfo metadata block and where a Vorbis comment metadata block is optional.", + "ja": "最初のパケットに続くのは、1つ以上のヘッダーパケットがあり、それぞれには単一のメタデータブロックが含まれています。これらのパケットの最初は、歴史的な理由でVorbisコメントメタデータブロックである必要があります。これは、カプセル化されていないFLACストリームに反します。メタデータブロックの順序は、Streaminfoメタデータブロックを除き、Vorbisコメントメタデータブロックがオプションである場合を除きます。" + }, + { + "indent": 3, + "text": "Following the header packets are audio packets. Each audio packet contains a single FLAC frame. The first audio packet MUST start on a new Ogg page, i.e., the last metadata block MUST finish its page before any audio packets are encapsulated.", + "ja": "ヘッダーパケットに続くのはオーディオパケットです。各オーディオパケットには、単一のFLACフレームが含まれています。最初のオーディオパケットは、新しいOGGページで開始する必要があります。つまり、オーディオパケットがカプセル化される前に、最後のメタデータブロックがページを終了する必要があります。" + }, + { + "indent": 3, + "text": "The granule position of all pages containing header packets MUST be 0. For pages containing audio packets, the granule position is the number of the last sample contained in the last completed packet in the frame. The sample numbering considers interchannel samples. If a page contains no packet end (e.g., when it only contains the start of a large packet that continues on the next page), then the granule position is set to the maximum value possible, i.e., 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF.", + "ja": "ヘッダーパケットを含むすべてのページの顆粒位置は0でなければなりません。オーディオパケットを含むページの場合、顆粒位置は、フレームの最後の完成したパケットに含まれる最後のサンプルの数です。サンプル番号は、チャネルインターチャネルサンプルを考慮します。ページにパケットエンドが含まれていない場合（たとえば、次のページで継続する大きなパケットの開始のみを含む場合）、顆粒位置は可能な最大値に設定されます。つまり、0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff。" + }, + { + "indent": 3, + "text": "The granule position of the first audio data page with a completed packet MAY be larger than the number of samples contained in packets that complete on that page. In other words, the apparent sample number of the first sample in the stream following from the granule position and the audio data MAY be larger than 0. This allows, for example, a server to cast a live stream to several clients that joined at different moments without rewriting the granule position for each client.", + "ja": "完成したパケットを使用した最初のオーディオデータページの顆粒位置は、そのページに完成するパケットに含まれるサンプルの数よりも大きい場合があります。言い換えれば、顆粒位置から続くストリームの最初のサンプルの見かけのサンプル番号とオーディオデータは0より大きくなる可能性があります。これにより、たとえば、異なるものに結合した複数のクライアントにライブストリームをキャストすることができます。各クライアントの顆粒位置を書き換えない瞬間。" + }, + { + "indent": 3, + "text": "If an audio stream is encoded where audio properties (sample rate, number of channels, or bit depth) change at some point in the stream, this should be dealt with by finishing encoding of the current Ogg stream and starting a new Ogg stream, concatenated to the previous one. This is called chaining in Ogg. See the Ogg specification [RFC3533] for details.", + "ja": "ストリームのある時点でオーディオプロパティ（サンプルレート、チャネル数、またはビット深度）が変更される場合にオーディオストリームがエンコードされている場合、これは現在のOGGストリームのエンコードを完了し、新しいOGGストリームを開始することで対処する必要があります。前のものに。これはOGGでチェーンと呼ばれます。詳細については、OGG仕様[RFC3533]を参照してください。" + }, + { + "indent": 0, + "text": "10.2. Matroska Mapping", + "section_title": true, + "ja": "10.2. マトロスカマッピング" + }, + { + "indent": 3, + "text": "The Matroska container format is defined in [RFC9559]. The codec ID (EBML path \\Segment\\Tracks\\TrackEntry\\CodecID) assigned to signal tracks carrying FLAC data is A_FLAC in ASCII. All FLAC data before the first audio frame (i.e., the fLaC ASCII signature and all metadata blocks) is stored as CodecPrivate data (EBML path \\Segment\\Tracks\\TrackEntry\\CodecPrivate).", + "ja": "マトロスカコンテナ形式は[RFC9559]で定義されています。FLACデータを運ぶ信号トラックに割り当てられたCodec ID（EBML PATH \\ Segment \\ Tracks \\ TrackEntry \\ CodeCID）は、ASCIIのA_FLACです。最初のオーディオフレームの前のすべてのFLACデータ（つまり、FLAC ASCII署名およびすべてのメタデータブロック）は、CodecPrivateデータ（EBML Path \\ segment \\ tracks \\ trackentry \\ codecprivate）として保存されます。" + }, + { + "indent": 3, + "text": "Each FLAC frame (including all of its subframes) is treated as a single frame in the context of Matroska.", + "ja": "各FLACフレーム（すべてのサブフレームを含む）は、マトロスカのコンテキストで単一のフレームとして扱われます。" + }, + { + "indent": 3, + "text": "If an audio stream is encoded where audio properties (sample rate, number of channels, or bit depth) change at some point in the stream, this should be dealt with by finishing the current Matroska segment and starting a new one with the new properties.", + "ja": "ストリームのある時点でオーディオプロパティ（サンプルレート、チャネル数、またはビット深度）が変更される場合にオーディオストリームがエンコードされている場合、これは現在のMatroskaセグメントを完了し、新しいプロパティで新しいものを開始することで対処する必要があります。" + }, + { + "indent": 0, + "text": "10.3. ISO Base Media File Format (MP4) Mapping", + "section_title": true, + "ja": "10.3. ISOベースメディアファイル形式（MP4）マッピング" + }, + { + "indent": 3, + "text": "The full encapsulation definition of FLAC audio in MP4 files was deemed too extensive to include in this document. A definition document can be found at [FLAC-in-MP4-specification].", + "ja": "MP4ファイルのFLACオーディオの完全なカプセル化定義は、このドキュメントに含めるには広すぎると見なされました。[FLAC-IN-MP4仕様]に定義ドキュメントがあります。" + }, + { + "indent": 0, + "text": "11. Security Considerations", + "section_title": true, + "ja": "11. セキュリティに関する考慮事項" + }, + { + "indent": 3, + "text": "Like any other codec (such as [RFC6716]), FLAC should not be used with insecure ciphers or cipher modes that are vulnerable to known plaintext attacks. Some of the header bits, as well as the padding, are easily predictable.", + "ja": "他のコーデック（[RFC6716]など）と同様に、FLACは、既知のプレーンテキスト攻撃に対して脆弱な不安定な暗号や暗号モードで使用しないでください。ヘッダービットの一部とパディングは、簡単に予測できます。" + }, + { + "indent": 3, + "text": "Implementations of the FLAC codec need to take appropriate security considerations into account. Section 2.1 of [RFC4732] provides general information on DoS attacks on end systems and describes some mitigation strategies. Areas of concern specific to FLAC follow.", + "ja": "FLACコーデックの実装は、適切なセキュリティ上の考慮事項を考慮する必要があります。[RFC4732]のセクション2.1は、ENDシステムに対するDOS攻撃に関する一般的な情報を提供し、いくつかの緩和戦略について説明します。FLACに固有の懸念領域が続きます。" + }, + { + "indent": 3, + "text": "It is extremely important for the decoder to be robust against malformed payloads. Payloads that do not conform to this specification MUST NOT cause the decoder to overrun its allocated memory or take an excessive amount of resources to decode. An overrun in allocated memory could lead to arbitrary code execution by an attacker. The same applies to the encoder, even though problems with encoders are typically rarer. Malformed audio streams MUST NOT cause the encoder to misbehave because this would allow an attacker to attack transcoding gateways.", + "ja": "デコーダーが奇形のペイロードに対して堅牢であることが非常に重要です。この仕様に準拠していないペイロードは、デコーダーが割り当てられたメモリをオーバーランさせたり、過度の量のリソースを取得してデコードしてはなりません。割り当てられたメモリのオーバーランは、攻撃者による任意のコード実行につながる可能性があります。エンコーダーの問題は通常よりまれですが、エンコーダーにも同じことが当てはまります。奇形のオーディオストリームは、攻撃者がトランスコーディングゲートウェイを攻撃できるため、エンコーダーを不正にしてはなりません。" + }, + { + "indent": 3, + "text": "As with all compression algorithms, both encoding and decoding can produce an output much larger than the input. For decoding, the most extreme possible case of this is a frame with eight constant subframes of block size 65535 and coding for 32-bit PCM. This frame is only 49 bytes in size but codes for more than 2 megabytes of uncompressed PCM data. For encoding, it is possible to have an even larger size increase, although such behavior is generally considered faulty. This happens if the encoder chooses a Rice parameter that does not fit with the residual that has to be encoded. In such a case, very long unary-coded symbols can appear (in the most extreme case, more than 4 gigabytes per sample). Decoder and encoder implementors are advised to take precautions to prevent excessive resource utilization in such cases.", + "ja": "すべての圧縮アルゴリズムと同様に、エンコードとデコードの両方が入力よりもはるかに大きい出力を生成する可能性があります。デコードの場合、これの最も極端なケースは、ブロックサイズ65535の8つの一定のサブフレームと32ビットPCMのコーディングを備えたフレームです。このフレームのサイズはわずか49バイトですが、2メガバイト以上の非圧縮PCMデータをコードします。エンコーディングの場合、そのような動作は一般に故障していると考えられていますが、さらに大きくサイズが増加する可能性があります。これは、エンコーダーがエンコードする必要がある残差に適合しないイネパラメーターを選択した場合に発生します。そのような場合、非常に長い単一コードされた記号が表示されます（最も極端な場合、サンプルごとに4ギガバイト以上）。デコーダーとエンコーダーの実装者は、そのような場合に過度のリソースの利用を防ぐために予防策を講じることをお勧めします。" + }, + { + "indent": 3, + "text": "Where metadata is handled, implementors are advised to either thoroughly test the handling of extreme cases or impose reasonable limits beyond the limits of this specification. For example, a single Vorbis comment metadata block can contain millions of valid fields. It is unlikely such a limit is ever reached except in a potentially malicious file. Likewise, the media type and description of a picture metadata block can be millions of characters long, despite there being no reasonable use of such contents. One possible use case for very long character strings is in lyrics, which can be stored in Vorbis comment metadata block fields.", + "ja": "メタデータが処理される場合、実装者は、極端なケースの取り扱いを徹底的にテストするか、この仕様の制限を超えて合理的な制限を課すことをお勧めします。たとえば、単一のVorbisコメントメタデータブロックには、何百万もの有効なフィールドを含めることができます。潜在的に悪意のあるファイルを除いて、このような制限に達する可能性は低いです。同様に、そのようなコンテンツの合理的な使用がないにもかかわらず、画像メタデータブロックのメディアタイプと説明は何百万人もの文字になります。非常に長いキャラクター文字列の可能なユースケースの1つは歌詞で、Vorbisコメントメタデータブロックフィールドに保存できます。" + }, + { + "indent": 3, + "text": "Various kinds of metadata blocks contain length fields or field counts. While reading a block following these lengths or counts, a decoder MUST make sure higher-level lengths or counts (most importantly, the length field of the metadata block itself) are not exceeded. As some of these length fields code string lengths and memory must be allocated for that, parsers MUST first verify that a block is valid before allocating memory based on its contents, except when explicitly instructed to salvage data from a malformed file.", + "ja": "さまざまな種類のメタデータブロックには、長さのフィールドまたはフィールド数が含まれています。これらの長さまたはカウントに続いてブロックを読み取っている間、デコーダーは、より高いレベルの長さまたはカウント（最も重要なことに、メタデータブロック自体の長さフィールド）を超えないことを確認する必要があります。これらの長さのフィールドの一部は、文字列の長さとメモリを割り当てる必要があるため、パーサーはまず、不正なファイルからデータをサルベージするように明示的に指示された場合を除き、その内容に基づいてメモリを割り当てる前にブロックが有効であることを確認する必要があります。" + }, + { + "indent": 3, + "text": "Metadata blocks can also contain references, e.g., the picture metadata block can contain a URI. When following a URI, the security considerations of [RFC3986] apply. Applications MUST obtain explicit user approval to retrieve resources via remote protocols. Following external URIs introduces a tracking risk from on-path observers and the operator of the service hosting the URI. Likewise, the choice of scheme, if it isn't protected like https, could also introduce integrity attacks by an on-path observer. A malicious operator of the service hosting the URI can return arbitrary content that the parser will read. Also, such retrievals can be used in a DDoS attack when the URI points to a potential victim. Therefore, applications need to ask user approval for each retrieval individually, take extra precautions when parsing retrieved data, and cache retrieved resources. Applications MUST obtain explicit user approval to retrieve local resources not located in the same directory as the FLAC file being processed. Since relative URIs are permitted, applications MUST guard against directory traversal attacks and guard against a violation of a same-origin policy if such a policy is being enforced.", + "ja": "メタデータブロックには参照を含めることもできます。たとえば、画像メタデータブロックにはURIを含めることができます。URIに従うと、[RFC3986]のセキュリティ上の考慮事項が適用されます。アプリケーションは、リモートプロトコルを介してリソースを取得するための明示的なユーザー承認を取得する必要があります。外部のURIに続いて、Path ObserversとURIをホストするサービスのオペレーターから追跡リスクを導入します。同様に、スキームの選択は、HTTPSのように保護されていない場合、パスでのオブザーバーによる整合性攻撃を導入することもできます。URIをホストするサービスの悪意のあるオペレーターは、パーサーが読む任意のコンテンツを返すことができます。また、URIが潜在的な犠牲者を指している場合、このような検索はDDOS攻撃で使用できます。したがって、アプリケーションは、各検索のユーザーの承認を個別に承認し、取得したデータを解析するときに追加の予防策を講じ、取得したリソースをキャッシュする必要があります。アプリケーションは、処理されているFLACファイルと同じディレクトリにないローカルリソースを取得するために、明示的なユーザー承認を取得する必要があります。相対的なURIは許可されているため、申請書はディレクトリのトラバーサル攻撃を防ぎ、そのようなポリシーが施行されている場合、同性ポリシーの違反を防ぐ必要があります。" + }, + { + "indent": 3, + "text": "Seeking in a FLAC stream that is not in a container relies on the coded number in frame headers and optionally a seek table metadata block. Parsers MUST employ thorough checks on whether a found coded number or seek point is at all possible, e.g., whether it is within bounds and not directly contradicting any other coded number or seek point that the seeking process relies on. Without these checks, seeking might get stuck in an infinite loop when numbers in frames are non-consecutive or otherwise not valid, which could be used in DoS attacks.", + "ja": "コンテナ内にないFLACストリームでの探索は、フレームヘッダーのコード化された数値に依存しており、オプションではシークテーブルメタデータブロックに依存しています。パーサーは、見つかったコード化された数字またはシークポイントが可能であるかどうかを徹底的なチェックを使用する必要があります。たとえば、それが範囲内であり、他のコード化された数値と直接矛盾しないか、シークプロセスが依存しているポイントを求めています。これらのチェックがなければ、Framesの数値が非継続的または無効である場合、DOS攻撃で使用できる場合、探すことは無限のループで立ち往生する可能性があります。" + }, + { + "indent": 3, + "text": "Implementors are advised to employ fuzz testing combined with different sanitizers on FLAC decoders to find security problems. Ignoring the results of CRC checks improves the efficiency of decoder fuzz testing.", + "ja": "実装者は、セキュリティの問題を見つけるために、FLACデコーダー上のさまざまな消毒剤と組み合わせたファズテストを採用することをお勧めします。CRCチェックの結果を無視すると、デコーダーファズテストの効率が向上します。" + }, + { + "indent": 3, + "text": "See [FLAC-decoder-testbench] for a non-exhaustive list of FLAC files with extreme configurations that lead to crashes or reboots on some known implementations. Besides providing a starting point for security testing, this set of files can also be used to test conformance with this specification.", + "ja": "[FLAC-Decoder-Testbench]を参照して、既知の実装でクラッシュまたは再起動につながる極端な構成を備えたFLACファイルの網羅的ではないリストを参照してください。セキュリティテストの出発点を提供することに加えて、この一連のファイルを使用して、この仕様との適合性をテストすることもできます。" + }, + { + "indent": 3, + "text": "FLAC files may contain executable code, although the FLAC format is not designed for it and it is uncommon. One use case where FLAC is occasionally used to store executable code is when compressing images of mixed-mode CDs, which contain both audio and non-audio data, the non-audio portion of which can contain executable code. In that case, the executable code is stored as if it were audio and is potentially obscured. Of course, it is also possible to store executable code as metadata, for example, as a Vorbis comment with help of a binary-to-text encoding or directly in an application metadata block. Applications MUST NOT execute code contained in FLAC files or present parts of FLAC files as executable code to the user, except when an application has that explicit purpose, e.g., applications reading FLAC files as disc images and presenting it as a virtual disc drive.", + "ja": "FLACファイルには実行可能なコードが含まれている場合がありますが、FLAC形式は設計されておらず、まれです。実行可能性コードの保存にFLACが時々使用される場合の1つのユースケースは、オーディオデータと非オーディオデータの両方を含む混合モードCDの画像を圧縮するときに、実行可能なコードを含むことができます。その場合、実行可能コードはオーディオであるかのように保存され、潜在的に不明瞭になります。もちろん、たとえば、実行可能性コードをメタデータとして保存することもできます。たとえば、バイナリからテキストのエンコードの助けを借りて、またはアプリケーションメタデータブロックに直接vorbisコメントとして保存することもできます。アプリケーションは、FLACファイルに含まれるコードを実行したり、FLACファイルの部分をユーザーに実行可能なコードとして提示したりしてはなりません。たとえば、アプリケーションにFLACファイルをDISC画像として読み取り、仮想ディスクドライブとして提示するアプリケーションがある場合を除きます。" + }, + { + "indent": 0, + "text": "12. IANA Considerations", + "section_title": true, + "ja": "12. IANAの考慮事項" + }, + { + "indent": 3, + "text": "Per this document, IANA has registered one new media type (\"audio/ flac\") and created a new IANA registry, as described in the subsections below.", + "ja": "このドキュメントに従って、IANAは1つの新しいメディアタイプ（「Audio/ FLAC」）を登録し、以下のサブセクションで説明するように、新しいIANAレジストリを作成しました。" + }, + { + "indent": 0, + "text": "12.1. Media Type Registration", + "section_title": true, + "ja": "12.1. メディアタイプの登録" + }, + { + "indent": 3, + "text": "IANA has registered the \"audio/flac\" media type as follows. This media type is applicable for FLAC audio that is not packaged in a container as described in Section 10. FLAC audio packaged in such a container will take on the media type of that container, for example, \"audio/ogg\" when packaged in an Ogg container or \"video/mp4\" when packaged in an MP4 container alongside a video track.", + "ja": "IANAは、次のように「オーディオ/FLAC」メディアタイプを登録しています。このメディアタイプは、セクション10で説明されているようにコンテナにパッケージ化されていないFLACオーディオに適用されます。そのようなコンテナにパッケージ化されたFLACオーディオは、そのコンテナのメディアタイプ、たとえば、「オーディオ/OGG」を使用します。MP4コンテナにビデオトラックと一緒にパッケージ化された場合、OGGコンテナまたは「ビデオ/MP4」。" + }, + { + "indent": 3, + "text": "Type name:", + "ja": "タイプ名：" + }, + { + "indent": 12, + "text": "audio", + "ja": "オーディオ" + }, + { + "indent": 3, + "text": "Subtype name:", + "ja": "サブタイプ名：" + }, + { + "indent": 12, + "text": "flac", + "ja": "FLAC" + }, + { + "indent": 3, + "text": "Required parameters:", + "ja": "必要なパラメーター：" + }, + { + "indent": 12, + "text": "N/A", + "ja": "n/a" + }, + { + "indent": 3, + "text": "Optional parameters:", + "ja": "オプションのパラメーター：" + }, + { + "indent": 12, + "text": "N/A", + "ja": "n/a" + }, + { + "indent": 3, + "text": "Encoding considerations:", + "ja": "考慮事項のエンコード：" + }, + { + "indent": 12, + "text": "as per RFC 9639", + "ja": "RFC 9639に従って" + }, + { + "indent": 3, + "text": "Security considerations:", + "ja": "セキュリティ上の考慮事項：" + }, + { + "indent": 12, + "text": "See the security considerations in Section 11 of RFC 9639.", + "ja": "RFC 9639のセクション11のセキュリティ上の考慮事項を参照してください。" + }, + { + "indent": 3, + "text": "Interoperability considerations:", + "ja": "相互運用性の考慮事項：" + }, + { + "indent": 12, + "text": "See the descriptions of past format changes in Appendix B of RFC 9639.", + "ja": "RFC 9639の付録Bの過去の形式の変更の説明を参照してください。" + }, + { + "indent": 3, + "text": "Published specification:", + "ja": "公開された仕様：" + }, + { + "indent": 12, + "text": "RFC 9639", + "ja": "RFC 9639" + }, + { + "indent": 3, + "text": "Applications that use this media type:", + "ja": "このメディアタイプを使用するアプリケーション：" + }, + { + "indent": 12, + "text": "FFmpeg, Apache, Firefox", + "ja": "ffmpeg、Apache、Firefox" + }, + { + "indent": 3, + "text": "Fragment identifier considerations:", + "ja": "フラグメント識別子の考慮事項：" + }, + { + "indent": 12, + "text": "N/A", + "ja": "n/a" + }, + { + "indent": 3, + "text": "Additional information:", + "ja": "追加情報：" + }, + { + "indent": 6, + "text": "Deprecated alias names for this type:", + "ja": "このタイプの非推奨エイリアス名：" + }, + { + "indent": 15, + "text": "audio/x-flac", + "ja": "オーディオ/X-FLAC" + }, + { + "indent": 6, + "text": "Magic number(s):", + "ja": "マジックナンバー：" + }, + { + "indent": 15, + "text": "fLaC", + "ja": "FLAC" + }, + { + "indent": 6, + "text": "File extension(s):", + "ja": "ファイル拡張子：" + }, + { + "indent": 15, + "text": "flac", + "ja": "FLAC" + }, + { + "indent": 6, + "text": "Macintosh file type code(s):", + "ja": "Macintoshファイルタイプコード：" + }, + { + "indent": 15, + "text": "N/A", + "ja": "n/a" + }, + { + "indent": 6, + "text": "Uniform Type Identifier:", + "ja": "均一型識別子：" + }, + { + "indent": 15, + "text": "org.xiph.flac conforms to public.audio", + "ja": "org.xiph.flacはpublic.audioに準拠しています" + }, + { + "indent": 6, + "text": "Windows Clipboard Format Name:", + "ja": "Windows Clipboardフォーマット名：" + }, + { + "indent": 15, + "text": "audio/flac", + "ja": "オーディオ/FLAC" + }, + { + "indent": 3, + "text": "Person & email address to contact for further information:", + "ja": "詳細については、連絡先への個人およびメールアドレス：" + }, + { + "indent": 12, + "text": "IETF CELLAR Working Group (cellar@ietf.org)", + "ja": "IETFセラーワーキンググループ（cellar@ietf.org）" + }, + { + "indent": 3, + "text": "Intended usage:", + "ja": "意図された使用法：" + }, + { + "indent": 12, + "text": "COMMON", + "ja": "一般" + }, + { + "indent": 3, + "text": "Restrictions on usage:", + "ja": "使用に関する制限：" + }, + { + "indent": 12, + "text": "N/A", + "ja": "n/a" + }, + { + "indent": 3, + "text": "Author:", + "ja": "著者：" + }, + { + "indent": 12, + "text": "IETF CELLAR Working Group", + "ja": "IETFセラーワーキンググループ" + }, + { + "indent": 3, + "text": "Change controller:", + "ja": "Change Controller：" + }, + { + "indent": 12, + "text": "Internet Engineering Task Force (iesg@ietf.org)", + "ja": "インターネットエンジニアリングタスクフォース（iesg@ietf.org）" + }, + { + "indent": 0, + "text": "12.2. FLAC Application Metadata Block IDs Registry", + "section_title": true, + "ja": "12.2. FLACアプリケーションメタデータブロックIDレジストリ" + }, + { + "indent": 3, + "text": "IANA has created a new registry called the \"FLAC Application Metadata Block IDs\" registry. The values correspond to the 32-bit identifier described in Section 8.4.", + "ja": "IANAは、「FLACアプリケーションメタデータブロックID」レジストリと呼ばれる新しいレジストリを作成しました。値は、セクション8.4で説明されている32ビット識別子に対応しています。" + }, + { + "indent": 3, + "text": "To register a new application ID in this registry, one needs an application ID, a description, an optional reference to a document describing the application ID, and a Change Controller (IETF or email of registrant). The application IDs are allocated according to the \"First Come First Served\" policy [RFC8126] so that there is no impediment to registering any application IDs the FLAC community encounters, especially if they were used in audio files but were not registered when the audio files were encoded. An application ID can be any 32-bit value but is often composed of 4 ASCII characters that are human-readable.", + "ja": "このレジストリに新しいアプリケーションIDを登録するには、アプリケーションID、説明、アプリケーションIDを説明するドキュメントへのオプションの参照、およびChange Controller（IETFまたは登録者の電子メール）が必要です。アプリケーションIDは、「First Come First」ポリシー[RFC8126]に従って割り当てられます。そのため、特にオーディオファイルで使用されているがオーディオファイルが登録されていない場合、FLACコミュニティの遭遇を登録することに障害がありません。エンコードされました。アプリケーションIDは任意の32ビット値にすることができますが、多くの場合、人間が読み取る可能性のある4つのASCII文字で構成されています。" + }, + { + "indent": 3, + "text": "The initial contents of \"FLAC Application Metadata Block IDs\" registry are shown in the table below. These initial values were taken from the registration page at xiph.org (see [ID-registration-page]), which is no longer being maintained as it has been replaced by this registry.", + "ja": "「FLACアプリケーションメタデータブロックID」レジストリの初期内容を以下の表に示します。これらの初期値は、xiph.orgの登録ページ（[id-registration-page]を参照）から取得されましたが、このレジストリに置き換えられたため、維持されなくなりました。" + }, + { + "indent": 1, + "text": " +===========+==========+===========+===================+==========+\n |Application|ASCII |Description|Reference |Change |\n |ID |Rendition | | |Controller|\n | |(If | | | |\n | |Available)| | | |\n +===========+==========+===========+===================+==========+\n |0x41544348 |ATCH |FlacFile |[FlacFile], RFC |IETF |\n | | | |9639 | |\n +-----------+----------+-----------+-------------------+----------+\n |0x42534F4C |BSOL |beSolo |RFC 9639 |IETF |\n +-----------+----------+-----------+-------------------+----------+\n |0x42554753 |BUGS |Bugs Player|RFC 9639 |IETF |\n +-----------+----------+-----------+-------------------+----------+\n |0x43756573 |Cues |GoldWave |RFC 9639 |IETF |\n | | |cue points | | |\n +-----------+----------+-----------+-------------------+----------+\n |0x46696361 |Fica |CUE |RFC 9639 |IETF |\n | | |Splitter | | |\n +-----------+----------+-----------+-------------------+----------+\n |0x46746F6C |Ftol |flac-tools |RFC 9639 |IETF |\n +-----------+----------+-----------+-------------------+----------+\n |0x4D4F5442 |MOTB |MOTB |RFC 9639 |IETF |\n | | |MetaCzar | | |\n +-----------+----------+-----------+-------------------+----------+\n |0x4D505345 |MPSE |MP3 Stream |RFC 9639 |IETF |\n | | |Editor | | |\n +-----------+----------+-----------+-------------------+----------+\n |0x4D754D4C |MuML |MusicML: |RFC 9639 |IETF |\n | | |Music | | |\n | | |Metadata | | |\n | | |Language | | |\n +-----------+----------+-----------+-------------------+----------+\n |0x52494646 |RIFF |Sound |RFC 9639 |IETF |\n | | |Devices | | |\n | | |RIFF chunk | | |\n | | |storage | | |\n +-----------+----------+-----------+-------------------+----------+\n |0x5346464C |SFFL |Sound Font |RFC 9639 |IETF |\n | | |FLAC | | |\n +-----------+----------+-----------+-------------------+----------+\n |0x534F4E59 |SONY |Sony |RFC 9639 |IETF |\n | | |Creative | | |\n | | |Software | | |\n +-----------+----------+-----------+-------------------+----------+\n |0x5351455A |SQEZ |flacsqueeze|RFC 9639 |IETF |\n +-----------+----------+-----------+-------------------+----------+\n |0x54745776 |TtWv |TwistedWave|RFC 9639 |IETF |\n +-----------+----------+-----------+-------------------+----------+\n |0x55495453 |UITS |UITS |RFC 9639 |IETF |\n | | |Embedding | | |\n | | |tools | | |\n +-----------+----------+-----------+-------------------+----------+\n |0x61696666 |aiff |FLAC AIFF |[Foreign-metadata],|IETF |\n | | |chunk |RFC 9639 | |\n | | |storage | | |\n +-----------+----------+-----------+-------------------+----------+\n |0x696D6167 |imag |flac-image |RFC 9639 |IETF |\n +-----------+----------+-----------+-------------------+----------+\n |0x7065656D |peem |Parseable |RFC 9639 |IETF |\n | | |Embedded | | |\n | | |Extensible | | |\n | | |Metadata | | |\n +-----------+----------+-----------+-------------------+----------+\n |0x71667374 |qfst |QFLAC |RFC 9639 |IETF |\n | | |Studio | | |\n +-----------+----------+-----------+-------------------+----------+\n |0x72696666 |riff |FLAC RIFF |[Foreign-metadata],|IETF |\n | | |chunk |RFC 9639 | |\n | | |storage | | |\n +-----------+----------+-----------+-------------------+----------+\n |0x74756E65 |tune |TagTuner |RFC 9639 |IETF |\n +-----------+----------+-----------+-------------------+----------+\n |0x77363420 |w64 |FLAC Wave64|[Foreign-metadata],|IETF |\n | | |chunk |RFC 9639 | |\n | | |storage | | |\n +-----------+----------+-----------+-------------------+----------+\n |0x78626174 |xbat |XBAT |RFC 9639 |IETF |\n +-----------+----------+-----------+-------------------+----------+\n |0x786D6364 |xmcd |xmcd |RFC 9639 |IETF |\n +-----------+----------+-----------+-------------------+----------+\n\n Table 25", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "13. References", + "section_title": true, + "ja": "13. 参考文献" + }, + { + "indent": 0, + "text": "13.1. Normative References", + "section_title": true, + "ja": "13.1. 引用文献" + }, + { + "indent": 3, + "text": "[ISRC-handbook]\n International ISRC Registration Authority, \"International\n Standard Recording Code (ISRC) Handbook\", 4th edition,\n 2021, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC1321] Rivest, R., \"The MD5 Message-Digest Algorithm\", RFC 1321,\n DOI 10.17487/RFC1321, April 1992,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC2046] Freed, N. and N. Borenstein, \"Multipurpose Internet Mail\n Extensions (MIME) Part Two: Media Types\", RFC 2046,\n DOI 10.17487/RFC2046, November 1996,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC2083] Boutell, T., \"PNG (Portable Network Graphics)\n Specification Version 1.0\", RFC 2083,\n DOI 10.17487/RFC2083, March 1997,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC2119] Bradner, S., \"Key words for use in RFCs to Indicate\n Requirement Levels\", BCP 14, RFC 2119,\n DOI 10.17487/RFC2119, March 1997,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC3533] Pfeiffer, S., \"The Ogg Encapsulation Format Version 0\",\n RFC 3533, DOI 10.17487/RFC3533, May 2003,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC3629] Yergeau, F., \"UTF-8, a transformation format of ISO\n 10646\", STD 63, RFC 3629, DOI 10.17487/RFC3629, November\n 2003, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, \"Uniform\n Resource Identifier (URI): Generic Syntax\", STD 66,\n RFC 3986, DOI 10.17487/RFC3986, January 2005,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8174] Leiba, B., \"Ambiguity of Uppercase vs Lowercase in RFC\n 2119 Key Words\", BCP 14, RFC 8174, DOI 10.17487/RFC8174,\n May 2017, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC9559] Lhomme, S., Bunkus, M., and D. Rice, \"Matroska Media\n Container Format Specification\", RFC 9559,\n DOI 10.17487/RFC9559, October 2024,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "13.2. Informative References", + "section_title": true, + "ja": "13.2. 参考引用" + }, + { + "indent": 3, + "text": "[Durbin] Durbin, J., \"The Fitting of Time-Series Models\", Revue de\n l'Institut International de Statistique / Review of the\n International Statistical Institute, vol. 28, no. 3, pp.\n 233-44, DOI 10.2307/1401322, 1960,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[FIR] Wikipedia, \"Finite impulse response\", August 2024,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[FLAC-decoder-testbench]\n \"The Free Lossless Audio Codec (FLAC) test files\", commit\n aa7b0c6, August 2023,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[FLAC-implementation]\n \"FLAC\", .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[FLAC-in-MP4-specification]\n \"Encapsulation of FLAC in ISO Base Media File Format\",\n commit 78d85dd, July 2022,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[FLAC-specification-github]\n \"The Free Lossless Audio Codec (FLAC) Specification\",\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[FLAC-wiki-interoperability]\n \"Interoperability considerations\", commit 58a06d6,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[FlacFile] \"FlacFile\", Wayback Machine archive, October 2007,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[Foreign-metadata]\n \"Specification of foreign metadata storage in FLAC\",\n commit 72787c3, November 2023,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[ID-registration-page]\n Xiph.Org, \"ID registry\", .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[ID3v2] Nilsson, M., \"ID3 tag version 2.4.0 - Native Frames\",\n Wayback Machine archive, November 2000,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[IEC.60908.1999]\n International Electrotechnical Commission, \"Audio\n recording - Compact disc digital audio system\",\n IEC 60908:1999-02, 1999,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[LinearPrediction]\n Wikipedia, \"Linear prediction\", August 2023,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[Lossless-Compression]\n Hans, M. and R. W. Schafer, \"Lossless compression of\n digital audio\", IEEE Signal Processing Magazine, vol. 18,\n no. 4, pp. 21-32, DOI 10.1109/79.939834, July 2001,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[lossyWAV] Hydrogenaudio Knowledgebase, \"lossyWAV\", July 2021,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[MLP] Gerzon, M. A., Craven, P. G., Stuart, J. R., Law, M. J.,\n and R. J. Wilson, \"The MLP Lossless Compression System\",\n Audio Engineering Society Conference: 17th International\n Conference: High-Quality Audio Codin, September 1999,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[MusicBrainz]\n MusicBrainz, \"Tags & Variables\", MusicBrainz Picard v2.10\n documentation, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, \"Internet\n Denial-of-Service Considerations\", RFC 4732,\n DOI 10.17487/RFC4732, December 2006,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC5334] Goncalves, I., Pfeiffer, S., and C. Montgomery, \"Ogg Media\n Types\", RFC 5334, DOI 10.17487/RFC5334, September 2008,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC6716] Valin, JM., Vos, K., and T. Terriberry, \"Definition of the\n Opus Audio Codec\", RFC 6716, DOI 10.17487/RFC6716,\n September 2012, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8126] Cotton, M., Leiba, B., and T. Narten, \"Guidelines for\n Writing an IANA Considerations Section in RFCs\", BCP 26,\n RFC 8126, DOI 10.17487/RFC8126, June 2017,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[Rice] Rice, R. F. and J. R. Plaunt, \"Adaptive Variable-Length\n Coding for Efficient Compression of Spacecraft Television\n Data\", IEEE Transactions on Communication Technology, vol.\n 19, no. 6, pp. 889-897, DOI 10.1109/TCOM.1971.1090789,\n December 1971,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[Robinson-TR156]\n Robinson, T., \"SHORTEN: Simple lossless and near-lossless\n waveform compression\", Cambridge University Engineering\n Department Technical Report CUED/F-INFENG/TR.156, December\n 1994, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[Shannon] Shannon, C. E., \"Communication in the Presence of Noise\",\n Proceedings of the IRE, vol. 37, no. 1, pp. 10-21,\n DOI 10.1109/JRPROC.1949.232969, January 1949,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[VarLengthCode]\n Wikipedia, \"Variable-length code\", April 2024,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[Vorbis] Xiph.Org, \"Ogg Vorbis I format specification: comment\n field and header specification\",\n .", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "Appendix A. Numerical Considerations", + "section_title": true, + "ja": "付録A. 数値的考慮事項" + }, + { + "indent": 3, + "text": "In order to maintain lossless behavior, all arithmetic used in encoding and decoding sample values must be done with integer data types to eliminate the possibility of introducing rounding errors associated with floating-point arithmetic. Use of floating-point representations in analysis (e.g., finding a good predictor or Rice parameter) is not a concern as long as the process of using the found predictor and Rice parameter to encode audio samples is implemented with only integer math.", + "ja": "ロスレス動作を維持するために、サンプル値のエンコードとデコードで使用されるすべての算術を整数データ型で行う必要があります。分析におけるフローティングポイント表現の使用（例：適切な予測因子またはイネパラメーターを見つける）は、見つかった予測子とイネパラメーターを使用してオーディオサンプルをエンコードするプロセスが整数数学のみで実装されている限り、懸念事項ではありません。" + }, + { + "indent": 3, + "text": "Furthermore, the possibility of integer overflow can be eliminated by using data types that are large enough. Choosing a 64-bit signed data type for all arithmetic involving sample values would make sure the possibility for overflow is eliminated, but usually, smaller data types are chosen for increased performance, especially in embedded devices. This appendix provides guidelines for choosing the appropriate data type for each step of encoding and decoding FLAC files.", + "ja": "さらに、整数オーバーフローの可能性は、十分に大きいデータ型を使用して排除できます。サンプル値を含むすべての算術に対して64ビットの署名されたデータ型を選択すると、オーバーフローの可能性が排除されることを確認しますが、通常、特に埋め込まれたデバイスでは、パフォーマンスの向上のために小さなデータ型が選択されます。この付録は、FLACファイルをエンコードおよびデコードする各ステップに適切なデータ型を選択するためのガイドラインを提供します。" + }, + { + "indent": 3, + "text": "In this appendix, signed data types are signed two's complement.", + "ja": "この付録では、署名されたデータ型が2つの補完に署名されています。" + }, + { + "indent": 0, + "text": "A.1. Determining the Necessary Data Type Size", + "section_title": true, + "ja": "A.1. 必要なデータ型サイズを決定します" + }, + { + "indent": 3, + "text": "To find the smallest data type size that is guaranteed not to overflow for a certain sequence of arithmetic operations, the combination of values producing the largest possible result should be considered.", + "ja": "一連の算術演算でオーバーフローしないように保証されている最小のデータ型サイズを見つけるには、可能な最大の結果を生成する値の組み合わせを考慮する必要があります。" + }, + { + "indent": 3, + "text": "For example, if two 16-bit signed integers are added, the largest possible result forms if both values are the largest number that can be represented with a 16-bit signed integer. To store the result, a signed integer data type with at least 17 bits is needed. Similarly, when adding 4 of these values, 18 bits are needed; when adding 8, 19 bits are needed, etc. In general, the number of bits necessary when adding numbers together is increased by the log base 2 of the number of values rounded up to the nearest integer. So, when adding 18 unknown values stored in 8-bit signed integers, we need a signed integer data type of at least 13 bits to store the result, as the log base 2 of 18 rounded up is 5.", + "ja": "たとえば、2つの16ビットの署名された整数が追加された場合、両方の値が16ビット署名整数で表すことができる最大の数値である場合、可能な最大の結果形式が追加されます。結果を保存するには、少なくとも17ビットの署名された整数データ型が必要です。同様に、これらの値のうち4つを追加する場合、18ビットが必要です。一般的に、8、19ビットを追加する場合、数値を追加するときに必要なビット数は、最寄りの整数に丸められた値の数のログベース2によって増加します。したがって、8ビットの署名された整数に保存されている18の未知の値を追加すると、結果を保存するために少なくとも13ビットの署名整数データ型が必要です。" + }, + { + "indent": 3, + "text": "When multiplying two numbers, the number of bits needed for the result is the size of the first number plus the size of the second number. For example, if a 16-bit signed integer is multiplied by another 16-bit signed integer, the result needs at least 32 bits to be stored without overflowing. To show this in practice, the largest signed value that can be stored in 4 bits is -8. (-8)*(-8) is 64, which needs at least 8 bits (signed) to store.", + "ja": "2つの数値を掛けると、結果に必要なビット数は、最初の数字のサイズと2番目の数字のサイズです。たとえば、16ビットの署名された整数に別の16ビットの署名整数を掛けている場合、結果はオーバーフローせずに保存するために少なくとも32ビットを必要とします。これを実際に示すために、4ビットで保存できる最大の署名値は-8です。（-8）*（-8）は64で、保存するには少なくとも8ビット（署名）が必要です。" + }, + { + "indent": 0, + "text": "A.2. Stereo Decorrelation", + "section_title": true, + "ja": "A.2. ステレオ分離" + }, + { + "indent": 3, + "text": "When stereo decorrelation is used, the side channel will have one extra bit of bit depth; see Section 4.2.", + "ja": "Stereoの分離を使用すると、サイドチャネルには少しのビット深度があります。セクション4.2を参照してください。" + }, + { + "indent": 3, + "text": "This means that while 16-bit signed integers have sufficient range to store samples from a fully decoded FLAC frame with a bit depth of 16 bits, the decoding of a side subframe in such a file will need a data type with at least 17 bits to store decoded subframe samples before undoing stereo decorrelation.", + "ja": "これは、16ビットの署名済み整数には、16ビットの少し深さの完全なデコードされたFLACフレームからサンプルを保存するのに十分な範囲があるが、そのようなファイルのサイドサブフレームのデコードには、少なくとも17ビットのデータ型が必要であることを意味します。ステレオ脱線を元に戻す前に、デコードされたサブフレームサンプルを保存します。" + }, + { + "indent": 3, + "text": "Most FLAC decoders store decoded (subframe) samples as 32-bit values, which is sufficient for files with bit depths up to (and including) 31 bits.", + "ja": "ほとんどのFLACデコーダは、デコードされた（サブフレーム）サンプルを32ビット値として保存します。これは、31ビットまでのビット深度（および含有）のファイルに十分です。" + }, + { + "indent": 0, + "text": "A.3. Prediction", + "section_title": true, + "ja": "A.3. 予測" + }, + { + "indent": 3, + "text": "A prediction (which is used to calculate the residual on encoding or added to the residual to calculate the sample value on decoding) is formed by multiplying and summing preceding sample values. In order to eliminate the possibility of integer overflow, the combination of preceding sample values and predictor coefficients producing the largest possible value should be considered.", + "ja": "予測（エンコード時に残差を計算するために使用されるか、デコードでサンプル値を計算するために残差に追加されます）は、前のサンプル値を乗算および合計することによって形成されます。整数のオーバーフローの可能性を排除するために、先行するサンプル値と可能な最大の値を生成する予測係数の組み合わせを考慮する必要があります。" + }, + { + "indent": 3, + "text": "To determine the size of the data type needed to calculate either a residual sample (on encoding) or an audio sample value (on decoding) in a fixed predictor subframe, the maximum possible value for these is calculated as described in Appendix A.1 and in the following table. For example, if a frame codes for 16-bit audio and has some form of stereo decorrelation, the subframe coding for the side channel would need 16+1+3 bits if a third-order fixed predictor is used.", + "ja": "固定予測サブフレームの残差サンプル（エンコード時）またはオーディオサンプル値（デコード時）のいずれかを計算するために必要なデータ型のサイズを決定するために、これらの最大値は、付録A.1および説明のように計算されます。次の表に。たとえば、フレームが16ビットオーディオをコードし、何らかの形のステレオ分離を備えている場合、サイドチャネルのサブフレームコーディングには、3次固定予測子が使用される場合は16+1+3ビットが必要です。" + }, + { + "indent": 2, + "text": " +=======+==============================+===============+=======+\n | Order | Calculation of Residual | Sample Values | Extra |\n | | | Summed | Bits |\n +=======+==============================+===============+=======+\n | 0 | a(n) | 1 | 0 |\n +-------+------------------------------+---------------+-------+\n | 1 | a(n) - a(n-1) | 2 | 1 |\n +-------+------------------------------+---------------+-------+\n | 2 | a(n) - 2 * a(n-1) + a(n-2) | 4 | 2 |\n +-------+------------------------------+---------------+-------+\n | 3 | a(n) - 3 * a(n-1) + 3 * | 8 | 3 |\n | | a(n-2) - a(n-3) | | |\n +-------+------------------------------+---------------+-------+\n | 4 | a(n) - 4 * a(n-1) + 6 * | 16 | 4 |\n | | a(n-2) - 4 * a(n-3) + a(n-4) | | |\n +-------+------------------------------+---------------+-------+\n\n Table 26", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Where:", + "ja": "ただし：" + }, + { + "indent": 6, + "text": "* n is the number of the sample being predicted.", + "ja": "* nは予測されるサンプルの数です。" + }, + { + "indent": 6, + "text": "* a(n) is the sample being predicted.", + "ja": "* A（n）は予測されるサンプルです。" + }, + { + "indent": 6, + "text": "* a(n-1) is the sample before the one being predicted, a(n-2) is the sample before that, etc.", + "ja": "* A（n-1）は、予測される前のサンプルであり、A（n-2）はその前のサンプルです。" + }, + { + "indent": 3, + "text": "For subframes with a linear predictor, the calculation is a little more complicated. Each prediction is the sum of several multiplications. Each of these multiply a sample value with a predictor coefficient. The extra bits needed can be calculated by adding the predictor coefficient precision (in bits) to the bit depth of the audio samples. To account for the summing of these multiplications, the log base 2 of the predictor order rounded up is added.", + "ja": "線形予測因子を使用したサブフレームの場合、計算はもう少し複雑です。各予測は、いくつかの乗算の合計です。これらのそれぞれは、サンプル値に予測係数を掛けます。必要な追加ビットは、音声サンプルのビット深さに予測係数精度（ビット）を追加することで計算できます。これらの乗算の合計を説明するために、切り上げられた予測順のログベース2が追加されます。" + }, + { + "indent": 3, + "text": "For example, if the sample bit depth of the source is 24, the current subframe encodes a side channel (see Section 4.2), the predictor order is 12, and the predictor coefficient precision is 15 bits, the minimum required size of the used signed integer data type is at least (24 + 1) + 15 + ceil(log2(12)) = 44 bits. As another example, with a side-channel subframe bit depth of 16, a predictor order of 8, and a predictor coefficient precision of 12 bits, the minimum required size of the used signed integer data type is (16 + 1) + 12 + ceil(log2(8)) = 32 bits.", + "ja": "たとえば、ソースのサンプルビット深度が24の場合、現在のサブフレームはサイドチャネルをエンコードし（セクション4.2を参照）、予測順序は12、予測係数精度は15ビットです。整数データ型は、少なくとも（24 + 1） + 15 + CEIL（log2（12））= 44ビットです。別の例として、16のサイドチャネルサブフレームビット深度、8の予測順、および12ビットの予測係数精度がある場合、使用されている署名された整数データ型の最小必要なサイズは（16 + 1） + 12 +ですCEIL（log2（8））= 32ビット。" + }, + { + "indent": 0, + "text": "A.4. Residual", + "section_title": true, + "ja": "A.4. 残差" + }, + { + "indent": 3, + "text": "As stated in Section 9.2.7, an encoder must make sure residual samples are representable by a 32-bit integer, signed two's complement, excluding the most negative value. As in the previous section, it is possible to calculate when residual samples already implicitly fit and when an additional check is needed. This implicit fit is achieved when residuals would fit a theoretical 31-bit signed integer, as that satisfies both of the mentioned criteria. When this implicit fit is not achieved, all residual values must be calculated and checked individually.", + "ja": "セクション9.2.7で述べたように、エンコーダーは、最も負の値を除く、32ビットの整数によって残留サンプルが表現できることを確認する必要があります。前のセクションと同様に、残留サンプルがすでに暗黙的に適合したときと追加のチェックが必要な時期を計算することができます。この暗黙の適合は、上記の両方の基準を満たすため、残差が理論的な31ビット署名整数に適合する場合に達成されます。この暗黙の適合が達成されない場合、すべての残差値を個別に計算してチェックする必要があります。" + }, + { + "indent": 3, + "text": "For the residual of a fixed predictor, the maximum residual sample size was already calculated in the previous section. However, for a linear predictor, the prediction is shifted right by a certain amount. The number of bits needed for the residual is the number of bits calculated in the previous section, reduced by the prediction right shift, and increased by one bit to account for the subtraction of the prediction from the current sample on encoding.", + "ja": "固定予測子の残差については、前のセクションで最大残留サンプルサイズがすでに計算されていました。ただし、線形予測因子の場合、予測は一定の量だけシフトされます。残差に必要なビットの数は、前のセクションで計算されたビットの数であり、予測の正しいシフトによって減少し、エンコーディングに関する現在のサンプルからの予測の減算を説明するために1ビット増加しました。" + }, + { + "indent": 3, + "text": "Taking the last example of the previous section, where 32 bits were needed for the prediction, the required data type size for the residual samples in case of a right shift of 10 bits would be 32 - 10 + 1 = 23 bits, which means it is not necessary to perform the aforementioned check.", + "ja": "予測に32ビットが必要だった前のセクションの最後の例を使用すると、10ビットの正しいシフトの場合に残留サンプルに必要なデータ型サイズは32-10 + 1 = 23ビットです。前述のチェックを実行するために必要ではありません。" + }, + { + "indent": 3, + "text": "As another example, when encoding 32-bit PCM with fixed predictors, all predictor orders must be checked. While the zero-order fixed predictor is guaranteed to have residual samples that fit a 32-bit signed integer, it might produce a residual sample value that is the most negative representable value of that 32-bit signed integer.", + "ja": "別の例として、固定予測子を使用して32ビットPCMをエンコードする場合、すべての予測順序を確認する必要があります。ゼロオーダーの固定予測子は、32ビットの署名整数に適合する残留サンプルを持つことが保証されていますが、その32ビット署名された整数の最も負の表現可能な値である残差サンプル値を生成する可能性があります。" + }, + { + "indent": 3, + "text": "Note that on decoding, while the residual sample values are limited to the aforementioned range, the predictions are not. This means that while the decoding of the residual samples can happen fully in 32-bit signed integers, decoders must be sure to execute the addition of each residual sample to its accompanying prediction with a signed integer data type that is wide enough, as with encoding.", + "ja": "デコード時には、残留サンプル値は前述の範囲に限定されていますが、予測はそうではないことに注意してください。つまり、残差サンプルのデコードは32ビットの署名済み整数で完全に発生する可能性がありますが、デコーダーは、エンコードと同様に、署名済みの整数データタイプを使用して、それぞれの残差サンプルを付随する予測に追加する必要があることを意味します。。" + }, + { + "indent": 0, + "text": "A.5. Rice Coding", + "section_title": true, + "ja": "A.5. 米コーディング" + }, + { + "indent": 3, + "text": "When folding (i.e., zigzag encoding) the residual sample values, no extra bits are needed when the absolute value of each residual sample is first stored in an unsigned data type of the size of the last step, then doubled, and then has one subtracted depending on whether the residual sample was positive or negative. However, many implementations choose to require one extra bit of data type size so zigzag encoding can happen in one step without a cast instead of the procedure described in the previous sentence.", + "ja": "残留サンプル値を折りたたむ（つまり、zigzagエンコード）の場合、各残差サンプルの絶対値が最初に最後のステップのサイズの符号なしデータ型に保存され、次に2倍になり、1つが減算された場合、余分なビットは必要ありません残留サンプルが陽性かマイナスかによって異なります。ただし、多くの実装は、前の文に記載されている手順ではなく、キャストなしで1つのステップでZigzagエンコードが発生する可能性があるため、1つの追加のデータ型サイズを必要とすることを選択します。" + }, + { + "indent": 0, + "text": "Appendix B. Past Format Changes", + "section_title": true, + "ja": "付録B. 過去の形式の変更" + }, + { + "indent": 3, + "text": "This informational appendix documents the changes made to the FLAC format over the years. This information might be of use when encountering FLAC files that were made with software following the format as it was before the changes documented in this appendix.", + "ja": "この情報付録には、長年にわたってFLAC形式に加えられた変更が記録されています。この情報は、この付録に文書化された変更の前に形式に従ってソフトウェアで作成されたFLACファイルに遭遇する場合に使用される場合があります。" + }, + { + "indent": 3, + "text": "The FLAC format was first specified in December 2000, and the bitstream format was considered frozen with the release of FLAC 1.0 (the reference encoder/decoder) in July 2001. Only changes made since this first stable release are considered in this appendix. Changes made to the FLAC streamable subset definition (see Section 7) are not considered.", + "ja": "FLAC形式は2000年12月に最初に指定され、BitStream形式は2001年7月にFLAC 1.0（参照エンコーダ/デコーダー）のリリースで凍結されたと見なされました。この最初の安定したリリースがこの付録で考慮されてから変更された変更のみが行われます。FLACストリーミング可能なサブセット定義（セクション7を参照）に加えられた変更は考慮されません。" + }, + { + "indent": 0, + "text": "B.1. Addition of Blocking Strategy Bit", + "section_title": true, + "ja": "B.1. ブロッキング戦略ビットの追加" + }, + { + "indent": 3, + "text": "Perhaps the largest backwards-incompatible change to the specification was published in July 2007. Before this change, variable block size streams were not explicitly marked as such by a flag bit in the frame header. A decoder had two ways to detect a variable block size stream: by comparing the minimum and maximum block sizes in the streaminfo metadata block (which are equal for a fixed block size stream) or by detecting a change of block size during a stream if a decoder did not receive a streaminfo metadata block, which could not happen at all in theory. As the meaning of the coded number in the frame header depends on whether or not a stream has a variable block size, this presented a problem: the meaning of the coded number could not be reliably determined. To fix this problem, one of the reserved bits was changed to be used as a blocking strategy bit. See also Section 9.1.", + "ja": "おそらく、仕様の最大の後方に取得しやすい変更は2007年7月に公開されました。この変更の前に、フレームヘッダーのフラグビットによって、可変ブロックサイズのストリームがそのように明示的にマークされていませんでした。デコーダーには、可変ブロックサイズのストリームを検出する2つの方法がありました。Streaminfoメタデータブロックの最小ブロックサイズと最大ブロックサイズ（固定ブロックサイズのストリームに等しい）を比較するか、またはストリーム中のブロックサイズの変更を検出することにより、デコーダーは、Streaminfoメタデータブロックを受け取りませんでしたが、理論的にはまったく発生することはできませんでした。フレームヘッダー内のコード化された数値の意味は、ストリームのブロックサイズが可変なかどうかに依存するため、これは問題を提示しました。コード化された数字の意味は確実に決定できませんでした。この問題を修正するために、予約されたビットの1つがブロッキング戦略ビットとして使用されるように変更されました。セクション9.1も参照してください。" + }, + { + "indent": 3, + "text": "Along with the addition of a new flag, the meaning of the block size bits (see Section 9.1.1) was subtly changed. Initially, block size bits patterns 0b0001-0b0101 and 0b1000-0b1111 could only be used for fixed block size streams, while 0b0110 and 0b0111 could be used for both fixed block size and variable block size streams. With this change, these restrictions were lifted, and patterns 0b0001-0b1111 are now used for both variable block size and fixed block size streams.", + "ja": "新しいフラグの追加に加えて、ブロックサイズビットの意味（セクション9.1.1を参照）が微妙に変更されました。最初に、ブロックサイズビットパターン0B0001-0B0101および0B1000-0B1111は固定ブロックサイズのストリームにのみ使用できますが、0B0110と0B0111は、固定ブロックサイズと可変ブロックサイズのストリームの両方に使用できます。この変更により、これらの制限は解除され、パターン0B0001-0B1111は、可変ブロックサイズと固定ブロックサイズのストリームの両方に使用されます。" + }, + { + "indent": 0, + "text": "B.2. Restriction of Encoded Residual Samples", + "section_title": true, + "ja": "B.2. エンコードされた残留サンプルの制限" + }, + { + "indent": 3, + "text": "Another change to the specification was deemed necessary during standardization by the CELLAR Working Group of the IETF. As specified in Section 9.2.7, a limit is imposed on residual samples. This limit was not specified prior to the IETF standardization effort. However, as far as was known to the working group, no FLAC encoder at that time produced FLAC files containing residual samples exceeding this limit. This is mostly because it is very unlikely to encounter residual samples exceeding this limit when encoding 24-bit PCM, and encoding of PCM with higher bit depths was not yet implemented in any known encoder. In fact, these FLAC encoders would produce corrupt files upon being triggered to produce such residual samples, and it is unlikely any non-experimental encoder would ever do so, even when presented with crafted material. Therefore, it was not expected that existing implementations would be rendered non-compliant by this change.", + "ja": "IETFのセラーワーキンググループによる標準化中に、仕様に対する別の変更が必要であるとみなされました。セクション9.2.7で指定されているように、残留サンプルに制限が課されます。この制限は、IETF標準化の取り組みの前に指定されていません。ただし、ワーキンググループに知られている限り、当時のFLACエンコーダーは、この制限を超える残留サンプルを含むFLACファイルを生成しませんでした。これは主に、24ビットPCMをエンコードするときにこの制限を超える残留サンプルに遭遇する可能性が非常に低く、ビット深さの高いPCMのエンコードが既知のエンコーダーにまだ実装されていないためです。実際、これらのFLACエンコーダーは、そのような残留サンプルを生成するようにトリガーされたときに破損したファイルを生成し、作られた素材が提示されたとしても、非実験的エンコーダーがそうすることはほとんどありません。したがって、この変更により、既存の実装が非準拠になるとは予想されていませんでした。" + }, + { + "indent": 0, + "text": "B.3. Addition of 5-Bit Rice Parameters", + "section_title": true, + "ja": "B.3. 5ビットライスパラメーターの追加" + }, + { + "indent": 3, + "text": "One significant addition to the format was the residual coding method using 5-bit Rice parameters. Prior to publication of this addition in July 2007, a partitioned Rice code with 4-bit Rice parameters was the only residual coding method specified. The range offered by this coding method proved too small when encoding 24-bit PCM; therefore, a second residual coding method was specified that was identical to the first, but with 5-bit Rice parameters.", + "ja": "この形式への重要な追加の1つは、5ビットライスパラメーターを使用した残差コーディング方法でした。2007年7月にこの追加が公開される前に、4ビットの米パラメーターを備えた分割済み稲法が指定された唯一の残留コーディング方法でした。このコーディング方法で提供される範囲は、24ビットPCMをエンコードすると小さすぎることが判明しました。したがって、2番目の残差コーディング方法が指定され、最初の残留コードと5ビットのイネパラメーターを使用しました。" + }, + { + "indent": 0, + "text": "B.4. Restriction of LPC Shift to Non-negative Values", + "section_title": true, + "ja": "B.4. LPCの制限は、非陰性値へのシフト" + }, + { + "indent": 3, + "text": "As stated in Section 9.2.6, the predictor right shift is a number signed two's complement, which MUST NOT be negative. This is because shifting a number to the right by a negative amount is undefined behavior in the C programming language standard. The intended behavior was that a positive number would be a right shift and a negative number would be a left shift. The FLAC reference encoder was changed in 2007 to not generate LPC subframes with a negative predictor right shift, as it turned out that the use of such subframes would only very rarely provide any benefit and the decoders that were already widely in use at that point were not able to handle such subframes.", + "ja": "セクション9.2.6で述べたように、予測因子の右シフトは、2人の補完署名数字であり、負のものであってはなりません。これは、マイナス量によって数値を右にシフトすることが、Cプログラミング言語標準で未定義の動作であるためです。意図した動作は、正の数が正しいシフトであり、負の数は左シフトになるということでした。FLACリファレンスエンコーダは2007年に変更され、ネガティブな予測子の右シフトでLPCサブフレームを生成しないように変更されました。そのようなサブフレームの使用は非常にめったに利益を提供しないことが判明し、その時点ですでに広く使用されていたデコーダーはこのようなサブフレームを処理できません。" + }, + { + "indent": 0, + "text": "Appendix C. Interoperability Considerations", + "section_title": true, + "ja": "付録C. 相互運用性の考慮事項" + }, + { + "indent": 3, + "text": "As documented in Appendix B, there have been some changes and additions to the FLAC format. Additionally, implementation of certain features of the FLAC format took many years, meaning early decoder implementations could not be tested against files with these features. Finally, many lower-quality FLAC decoders only implement just enough features required for playback of the most common FLAC files.", + "ja": "付録Bに文書化されているように、FLAC形式にいくつかの変更と追加がありました。さらに、FLAC形式の特定の機能の実装には何年もかかりました。つまり、これらの機能を備えたファイルに対して初期のデコーダー実装をテストできませんでした。最後に、多くの低品質のFLACデコーダは、最も一般的なFLACファイルの再生に必要な十分な機能のみを実装します。" + }, + { + "indent": 3, + "text": "This appendix provides some considerations for encoder implementations aiming to create highly compatible files. As this topic is one that might change after this document is published, consult [FLAC-wiki-interoperability] for more up-to-date information.", + "ja": "この付録は、互換性の高いファイルを作成することを目的としたエンコーダーの実装に関するいくつかの考慮事項を提供します。このトピックは、このドキュメントが公開された後に変更される可能性のあるトピックであるため、最新情報については[FLAC-Wikiインターパラリティ]を参照してください。" + }, + { + "indent": 0, + "text": "C.1. Features outside of the Streamable Subset", + "section_title": true, + "ja": "C.1. ストリーミング可能なサブセットの外側の機能" + }, + { + "indent": 3, + "text": "As described in Section 7, FLAC specifies a subset of its capabilities as the FLAC streamable subset. Certain decoders may choose to only decode FLAC files conforming to the limitations imposed by the streamable subset. Therefore, maximum compatibility with decoders is achieved when the limitations of the FLAC streamable subset are followed when creating FLAC files.", + "ja": "セクション7で説明されているように、FLACはその機能のサブセットをFLACストリーミング可能なサブセットとして指定します。特定のデコーダは、ストリーミング可能なサブセットによって課される制限に準拠したFLACファイルのみをデコードすることを選択できます。したがって、FLACファイルを作成するときにFLACストリーミング可能なサブセットの制限が続くと、デコーダーとの最大互換性が達成されます。" + }, + { + "indent": 0, + "text": "C.2. Variable Block Size", + "section_title": true, + "ja": "C.2. 可変ブロックサイズ" + }, + { + "indent": 3, + "text": "Because it is often difficult to find the optimal arrangement of block sizes for maximum compression, most encoders choose to create files with a fixed block size. Because of this, many decoder implementations receive minimal use when handling variable block size streams, and this can reveal bugs or reveal that implementations do not decode them at all. Furthermore, as explained in Appendix B.1, there have been some changes to the way variable block size streams are encoded. Because of this, maximum compatibility with decoders is achieved when FLAC files are created using fixed block size streams.", + "ja": "最大の圧縮のためにブロックサイズの最適な配置を見つけることはしばしば困難であるため、ほとんどのエンコーダは固定ブロックサイズのファイルを作成することを選択します。このため、多くのデコーダーの実装は、可変ブロックサイズのストリームを処理するときに最小限の使用を受けます。これにより、バグが明らかになったり、実装がそれらをデコードしないことを明らかにします。さらに、付録B.1で説明したように、可変ブロックサイズのストリームがエンコードされる方法にいくつかの変更がありました。このため、FLACファイルが固定ブロックサイズのストリームを使用して作成されると、デコーダーとの最大互換性が達成されます。" + }, + { + "indent": 0, + "text": "C.3. 5-Bit Rice Parameters", + "section_title": true, + "ja": "C.3. 5ビットライスパラメーター" + }, + { + "indent": 3, + "text": "As the addition of the coding method using 5-bit Rice parameters, as described in Appendix B.3, occurred quite a few years after the FLAC format was first introduced, some early decoders might not be able to decode files containing such Rice parameters. The introduction of this was specifically aimed at improving compression of 24-bit PCM audio, and compression of 16-bit PCM audio only rarely benefits from using 5-bit Rice parameters. Therefore, maximum compatibility with decoders is achieved when FLAC files containing audio with a bit depth of 16 bits or less are created without any use of 5-bit Rice parameters.", + "ja": "付録B.3で説明されているように、5ビットイネパラメーターを使用したコーディング法の追加は、FLAC形式が最初に導入されてから数年後に発生したため、一部の初期デコーダはそのようなイネパラメーターを含むファイルをデコードできない可能性があります。これの導入は、24ビットPCMオーディオの圧縮を改善することを特に目的としており、16ビットPCMオーディオの圧縮は、5ビットライスパラメーターを使用することではめったに有益ではありません。したがって、5ビットライスパラメーターを使用せずに16ビット以下の少し深さのオーディオを含むFLACファイルが作成されると、デコーダーとの最大互換性が達成されます。" + }, + { + "indent": 0, + "text": "C.4. Rice Escape Code", + "section_title": true, + "ja": "C.4. ライスエスケープコード" + }, + { + "indent": 3, + "text": "Escaped Rice partitions are seldom used, as it turned out their use provides only a very small compression improvement. As many encoders do not use these by default or are not capable of producing them at all, it is likely that many decoder implementations are not able to decode them correctly. Therefore, maximum compatibility with decoders is achieved when FLAC files are created without any use of escaped Rice partitions.", + "ja": "脱出した米のパーティションはめったに使用されません。それは、それらの使用が非常に小さな圧縮改善のみを提供することが判明したためです。多くのエンコーダーはデフォルトでこれらを使用していないか、まったく生成できないため、多くのデコーダー実装では正しくデコードできない可能性があります。したがって、脱出されたライスパーティションを使用せずにFLACファイルを作成すると、デコーダーとの最大互換性が達成されます。" + }, + { + "indent": 0, + "text": "C.5. Uncommon Block Size", + "section_title": true, + "ja": "C.5. まれなブロックサイズ" + }, + { + "indent": 3, + "text": "For unknown reasons, some decoders have chosen to support only common block sizes for all but the last block of a stream. Therefore, maximum compatibility with decoders is achieved when creating FLAC files using common block sizes, as listed in Section 9.1.1, for all but the last block of a stream.", + "ja": "不明な理由で、一部のデコーダーは、ストリームの最後のブロックを除くすべてのすべての一般的なブロックサイズのみをサポートすることを選択しています。したがって、ストリームの最後のブロックを除くすべてのセクション9.1.1にリストされているように、一般的なブロックサイズを使用してFLACファイルを作成するときにデコーダーとの最大互換性が達成されます。" + }, + { + "indent": 0, + "text": "C.6. Uncommon Bit Depth", + "section_title": true, + "ja": "C.6. 珍しいビットの深さ" + }, + { + "indent": 3, + "text": "Most audio is stored in bit depths that are a whole number of bytes, e.g., 8, 16, or 24 bits. However, there is audio with different bit depths. A few examples:", + "ja": "ほとんどのオーディオは、たとえば8、16、または24ビットなどのバイトのビット深さで保存されます。ただし、ビットの深さが異なるオーディオがあります。いくつかの例：" + }, + { + "indent": 6, + "text": "* DVD-Audio has the possibility to store 20-bit PCM audio.", + "ja": "* DVD-Audioには、20ビットのPCMオーディオを保存する可能性があります。" + }, + { + "indent": 6, + "text": "* DAT and DV can store 12-bit PCM audio.", + "ja": "* DATとDVは、12ビットPCMオーディオを保存できます。" + }, + { + "indent": 6, + "text": "* NICAM-728 samples at 14 bits, which is companded to 10 bits.", + "ja": "* NICAM-728は14ビットでサンプルされ、10ビットに互換性があります。" + }, + { + "indent": 6, + "text": "* 8-bit µ-law can be losslessly converted to 14-bit (Linear) PCM.", + "ja": "* 8ビットµ-lawは、14ビット（線形）PCMに損失を無効に変換できます。" + }, + { + "indent": 6, + "text": "* 8-bit A-law can be losslessly converted to 13-bit (Linear) PCM.", + "ja": "* 8ビットA-Lawは、13ビット（線形）PCMに損失を無効に変換できます。" + }, + { + "indent": 3, + "text": "The FLAC format can contain these bit depths directly, but because they are uncommon, some decoders are not able to process the resulting files correctly. It is possible to store these formats in a FLAC file with a more common bit depth without sacrificing compression by padding each sample with zero bits to a bit depth that is a whole byte. The FLAC format can efficiently compress these wasted bits. See Section 9.2.2 for details.", + "ja": "FLAC形式にはこれらのビットの深さを直接含めることができますが、それらは珍しいため、一部のデコーダは結果のファイルを正しく処理できません。これらの形式は、各サンプルをゼロビットでパディングして、バイト全体であるビット深度にパディングすることにより、より一般的なビット深度のFLACファイルに保存することができます。FLAC形式は、これらの無駄なビットを効率的に圧縮できます。詳細については、セクション9.2.2を参照してください。" + }, + { + "indent": 3, + "text": "Therefore, maximum compatibility with decoders is achieved when FLAC files are created by padding samples of such audio with zero bits to the bit depth that is the next whole number of bytes.", + "ja": "したがって、次のバイトのビット深さまでビットゼロのビットを持つこのようなオーディオのサンプルをパディングすることによってFLACファイルが作成されると、デコーダーとの最大互換性が達成されます。" + }, + { + "indent": 3, + "text": "In cases where the original signal is already padded, this operation cannot be reversed losslessly without knowing the original bit depth. To leave no ambiguity, the original bit depth needs to be stored, for example, in a Vorbis comment field or by storing the header of the original file. The choice of a suitable method is left to the implementor.", + "ja": "元の信号が既にパッドが付けられている場合、この操作は、元のビットの深さを知らなくても損失を無効にすることはできません。あいまいさを残さないには、元のビット深度を、たとえば、Vorbisのコメントフィールドまたは元のファイルのヘッダーを保存して保存する必要があります。適切な方法の選択は、実装者に任されています。" + }, + { + "indent": 3, + "text": "Besides audio with a \"non-whole byte\" bit depth, some decoder implementations have chosen to only accept FLAC files coding for PCM audio with a bit depth of 16 bits. Many implementations support bit depths up to 24 bits, but no higher. Consult [FLAC-wiki-interoperability] for more up-to-date information.", + "ja": "「非wholeバイト」ビットの深さを備えたオーディオに加えて、一部のデコーダー実装は、16ビットの深さでPCMオーディオをコーディングするFLACファイルのみを受け入れるように選択されています。多くの実装は、最大24ビットまでのビットの深さをサポートしていますが、高くはありません。最新情報については、[FLAC-Wiki-interoperability]を参照してください。" + }, + { + "indent": 0, + "text": "C.7. Multi-Channel Audio and Uncommon Sample Rates", + "section_title": true, + "ja": "C.7. マルチチャネルオーディオおよび珍しいサンプルレート" + }, + { + "indent": 3, + "text": "Many FLAC audio players are unable to render multi-channel audio or audio with an uncommon sample rate. While this is not a concern specific to the FLAC format, it is of note when requiring maximum compatibility with decoders. Unlike the previously mentioned interoperability considerations, this is one where compatibility cannot be improved without sacrificing the lossless nature of the FLAC format.", + "ja": "多くのFLACオーディオプレーヤーは、珍しいサンプルレートでマルチチャネルオーディオまたはオーディオをレンダリングすることができません。これはFLAC形式に固有の懸念ではありませんが、デコーダーとの最大の互換性が必要な場合は注目に値します。前述の相互運用性の考慮事項とは異なり、これはFLAC形式のロスレス性を犠牲にせずに互換性を改善できない場合です。" + }, + { + "indent": 3, + "text": "From a non-exhaustive inquiry, it seems that a non-negligible number of players, especially hardware players, do not support audio with 3 or more channels or sample rates other than those considered common; see Section 9.1.2.", + "ja": "網羅的ではない問い合わせから、非交渉不可能な数のプレーヤー、特にハードウェアプレーヤーは、一般的と見なされるもの以外の3つ以上のチャネルまたはサンプルレートでオーディオをサポートしていないようです。セクション9.1.2を参照してください。" + }, + { + "indent": 3, + "text": "For those players that do support and are able to render multi-channel audio, many do not parse and use the WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag (see Section 8.6.2). This is also an interoperability consideration because compatibility cannot be improved without sacrificing the lossless nature of the FLAC format.", + "ja": "サポートし、マルチチャネルオーディオをレンダリングできるプレーヤーの場合、多くは波形Xtensible_channel_maskタグを解析して使用しません（セクション8.6.2を参照）。これは、FLAC形式の損失のない性質を犠牲にせずに互換性を改善できないため、相互運用性の考慮事項でもあります。" + }, + { + "indent": 0, + "text": "C.8. Changing Audio Properties Mid-Stream", + "section_title": true, + "ja": "C.8. オーディオプロパティの変更中間ストリーム" + }, + { + "indent": 3, + "text": "Each FLAC frame header stores the audio sample rate, number of bits per sample, and number of channels independently of the streaminfo metadata block and other frame headers. This was done to permit multicasting of FLAC files, but it also allows these properties to change mid-stream. However, many FLAC decoders do not handle such changes, as few other formats are capable of holding such streams and changing playback properties during playback is often not possible without interrupting playback. Also, as explained in Section 9, using this feature of FLAC results in various practical problems.", + "ja": "各FLACフレームヘッダーは、オーディオサンプルレート、サンプルあたりのビット数、およびStreaminfoメタデータブロックおよびその他のフレームヘッダーとは無関係にチャネルの数を保存します。これは、FLACファイルのマルチキャストを許可するために行われましたが、これらのプロパティが中間ストリームを変更することもできます。ただし、多くのFLACデコーダーはそのような変更を処理しません。再生中にそのようなストリームを保持し、再生プロパティを変更することができる他の形式はほとんどないため、再生を中断することなく不可能です。また、セクション9で説明されているように、FLACのこの機能を使用すると、さまざまな実用的な問題が発生します。" + }, + { + "indent": 3, + "text": "However, even when storing an audio stream with changing properties in FLAC encapsulated in a container capable of handling such changes, as recommended in Section 9, many decoders are not able to decode such a stream correctly. Therefore, maximum compatibility with decoders is achieved when FLAC files are created with a single set of audio properties, in which the properties coded in the streaminfo metadata block (see Section 8.2) and the properties coded in all frame headers (see Section 9.1) are the same. This can be achieved by splitting up an input stream with changing audio properties at the points where these properties change into separate streams or files.", + "ja": "ただし、セクション9で推奨されるように、このような変更を処理できるコンテナにカプセル化されたFLACのプロパティの変更を伴うオーディオストリームを保存する場合でも、多くのデコーダーはそのようなストリームを正しくデコードできません。したがって、FLACファイルが単一のオーディオプロパティセットで作成された場合、Decodersとの最大互換性が達成されます。このプロパティでは、Streaminfoメタデータブロックにコード化されたプロパティ（セクション8.2を参照）と、すべてのフレームヘッダーでコーディングされたプロパティ（セクション9.1を参照）が作成されます。同じ。これは、これらのプロパティが個別のストリームまたはファイルに変更されるポイントで、オーディオプロパティの変更で入力ストリームを分割することで実現できます。" + }, + { + "indent": 0, + "text": "Appendix D. Examples", + "section_title": true, + "ja": "付録D. 例" + }, + { + "indent": 3, + "text": "This informational appendix contains short examples of FLAC files that are decoded step by step. These examples provide a more engaging way to understand the FLAC format than the formal specification. The text explaining these examples assumes the reader has at least cursorily read the specification and that the reader refers to the specification for explanation of the terminology used. These examples mostly focus on the layout of several metadata blocks, subframe types, and the implications of certain aspects (e.g., wasted bits and stereo decorrelation) on this layout.", + "ja": "この情報付録には、段階的にデコードされたFLACファイルの短い例が含まれています。これらの例は、正式な仕様よりもFLAC形式を理解するためのより魅力的な方法を提供します。これらの例を説明するテキストは、読者が少なくとも仕様を大まかに読んでおり、読者が使用された用語の説明の仕様を参照していることを前提としています。これらの例は、主に、いくつかのメタデータブロック、サブフレームタイプのレイアウト、およびこのレイアウトの特定の側面（無駄なビットやステレオの切り離関連）の意味に焦点を当てています。" + }, + { + "indent": 3, + "text": "The examples feature files generated by various FLAC encoders. These are presented in hexadecimal or binary format, followed by tables and text referring to various features by their starting bit positions in these representations. Each starting position (shortened to \"start\" in the tables) is a hexadecimal byte position and a start bit within that byte, separated by a plus sign. Counts for these start at zero. For example, a feature starting at the 3rd bit of the 17th byte is referred to as starting at 0x10+2. The files that are explored in these examples can be found at [FLAC-specification-github].", + "ja": "この例は、さまざまなFLACエンコーダーによって生成されたファイルを機能させます。これらは16進形式またはバイナリ形式で提示され、次にこれらの表現での開始ビット位置によるさまざまな機能を参照するテーブルとテキストが続きます。各開始位置（テーブル内の「開始」に短縮）は、六分位バイトの位置であり、そのバイト内のスタートビットで、プラス記号で区切られています。これらのカウントはゼロで開始します。たとえば、17番目のバイトの3番目のビットから始まる機能は、0x10+2から始まると呼ばれます。これらの例で調査されているファイルは、[FLAC仕様-Github]にあります。" + }, + { + "indent": 3, + "text": "All data in this appendix has been thoroughly verified. However, as this appendix is informational, if any information here conflicts with statements in the formal specification, the latter takes precedence.", + "ja": "この付録のすべてのデータは徹底的に検証されています。ただし、この付録は情報提供であるため、ここでの情報が正式な仕様の声明と矛盾する場合、後者は優先されます。" + }, + { + "indent": 0, + "text": "D.1. Decoding Example 1", + "section_title": true, + "ja": "D.1. デコード例1" + }, + { + "indent": 3, + "text": "This very short example FLAC file codes for PCM audio that has two channels, each containing one sample. The focus of this example is on the essential parts of a FLAC file.", + "ja": "この非常に短い例FLACファイルは、2つのチャネルがあり、それぞれに1つのサンプルが含まれているPCMオーディオのコードをコードしています。この例の焦点は、FLACファイルの重要な部分にあります。" + }, + { + "indent": 0, + "text": "D.1.1. Example File 1 in Hexadecimal Representation", + "section_title": true, + "ja": "D.1.1. 16進表現の例ファイル1" + }, + { + "indent": 3, + "text": "00000000: 664c 6143 8000 0022 1000 1000 fLaC...\"....\n0000000c: 0000 0f00 000f 0ac4 42f0 0000 ........B...\n00000018: 0001 3e84 b418 07dc 6903 0758 ..>.....i..X\n00000024: 6a3d ad1a 2e0f fff8 6918 0000 j=......i...\n00000030: bf03 58fd 0312 8baa 9a ..X......", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "D.1.2. Example File 1 in Binary Representation", + "section_title": true, + "ja": "D.1.2. バイナリ表現の例ファイル1" + }, + { + "indent": 3, + "text": "00000000: 01100110 01001100 01100001 01000011 fLaC\n00000004: 10000000 00000000 00000000 00100010 ...\"\n00000008: 00010000 00000000 00010000 00000000 ....\n0000000c: 00000000 00000000 00001111 00000000 ....\n00000010: 00000000 00001111 00001010 11000100 ....\n00000014: 01000010 11110000 00000000 00000000 B...\n00000018: 00000000 00000001 00111110 10000100 ..>.\n0000001c: 10110100 00011000 00000111 11011100 ....\n00000020: 01101001 00000011 00000111 01011000 i..X\n00000024: 01101010 00111101 10101101 00011010 j=..\n00000028: 00101110 00001111 11111111 11111000 ....\n0000002c: 01101001 00011000 00000000 00000000 i...\n00000030: 10111111 00000011 01011000 11111101 ..X.\n00000034: 00000011 00010010 10001011 10101010 ....\n00000038: 10011010", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "D.1.3. Signature and Streaminfo", + "section_title": true, + "ja": "D.1.3. 署名とStreaminfo" + }, + { + "indent": 3, + "text": "The first 4 bytes of the file contain the fLaC file signature. Directly following it is a metadata block. The signature and the first metadata block header are broken down in the following table.", + "ja": "ファイルの最初の4バイトには、FLACファイルの署名が含まれています。直接続くのはメタデータブロックです。署名と最初のメタデータブロックヘッダーは、次の表に分解されます。" + }, + { + "indent": 4, + "text": " +========+=========+============+===========================+\n | Start | Length | Contents | Description |\n +========+=========+============+===========================+\n | 0x00+0 | 4 bytes | 0x664C6143 | fLaC |\n +--------+---------+------------+---------------------------+\n | 0x04+0 | 1 bit | 0b1 | Last metadata block |\n +--------+---------+------------+---------------------------+\n | 0x04+1 | 7 bits | 0b0000000 | Streaminfo metadata block |\n +--------+---------+------------+---------------------------+\n | 0x05+0 | 3 bytes | 0x000022 | Length of 34 bytes |\n +--------+---------+------------+---------------------------+\n\n Table 27", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "As the header indicates that this is the last metadata block, the position of the first audio frame can now be calculated as the position of the first byte after the metadata block header + the length of the block, i.e., 8+34 = 42 or 0x2a. Thus, 0x2a indeed contains the frame sync code for fixed block size streams -- 0xfff8.", + "ja": "ヘッダーはこれが最後のメタデータブロックであることを示しているため、最初のオーディオフレームの位置は、メタデータブロックヘッダー +ブロックの長さ、つまり8 + 34 = 42または0x2a。したがって、0x2aには、固定ブロックサイズストリームのフレーム同期コード-0xfff8が含まれています。" + }, + { + "indent": 3, + "text": "The streaminfo metadata block contents are broken down in the following table.", + "ja": "Streaminfoメタデータブロックの内容は、次の表に分解されます。" + }, + { + "indent": 0, + "text": "+========+==========+====================+==========================+\n| Start | Length | Contents | Description |\n+========+==========+====================+==========================+\n| 0x08+0 | 2 bytes | 0x1000 | Min. block size 4096 |\n+--------+----------+--------------------+--------------------------+\n| 0x0a+0 | 2 bytes | 0x1000 | Max. block size 4096 |\n+--------+----------+--------------------+--------------------------+\n| 0x0c+0 | 3 bytes | 0x00000f | Min. frame size 15 bytes |\n+--------+----------+--------------------+--------------------------+\n| 0x0f+0 | 3 bytes | 0x00000f | Max. frame size 15 bytes |\n+--------+----------+--------------------+--------------------------+\n| 0x12+0 | 20 bits | 0x0ac4, 0b0100 | Sample rate 44100 hertz |\n+--------+----------+--------------------+--------------------------+\n| 0x14+4 | 3 bits | 0b001 | 2 channels |\n+--------+----------+--------------------+--------------------------+\n| 0x14+7 | 5 bits | 0b01111 | Sample bit depth 16 |\n+--------+----------+--------------------+--------------------------+\n| 0x15+4 | 36 bits | 0b0000, 0x00000001 | Total no. of samples 1 |\n+--------+----------+--------------------+--------------------------+\n| 0x1a | 16 | (...) | MD5 checksum |\n| | bytes | | |\n+--------+----------+--------------------+--------------------------+\n\n Table 28", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "The minimum and maximum block sizes are both 4096. This was apparently the block size the encoder planned to use, but as only 1 interchannel sample was provided, no frames with 4096 samples are actually present in this file.", + "ja": "最小および最大ブロックサイズはどちらも4096です。これは明らかにエンコーダーが使用する予定のブロックサイズでしたが、1つのインターチャネルサンプルのみが提供されたため、このファイルには4096サンプルのフレームは実際にはありません。" + }, + { + "indent": 3, + "text": "Note that anywhere a number of samples is mentioned (block size, total number of samples, sample rate), interchannel samples are meant.", + "ja": "多数のサンプルが言及されている場所（ブロックサイズ、サンプルの総数、サンプルレート）、インターチャネルサンプルが意味されることに注意してください。" + }, + { + "indent": 3, + "text": "The MD5 checksum (starting at 0x1a) is 0x3e84 b418 07dc 6903 0758 6a3d ad1a 2e0f. This will be validated after decoding the samples.", + "ja": "MD5チェックサム（0x1aから始まる）は0x3E84 B418 07DC 6903 0758 6A3D AD1A 2E0Fです。これは、サンプルをデコードした後に検証されます。" + }, + { + "indent": 0, + "text": "D.1.4. Audio Frames", + "section_title": true, + "ja": "D.1.4. オーディオフレーム" + }, + { + "indent": 3, + "text": "The frame header starts at position 0x2a and is broken down in the following table.", + "ja": "フレームヘッダーは位置0x2aから始まり、次の表で分解されます。" + }, + { + "indent": 5, + "text": " +========+=========+=================+===================+\n | Start | Length | Contents | Description |\n +========+=========+=================+===================+\n | 0x2a+0 | 15 bits | 0xff, 0b1111100 | Frame sync |\n +--------+---------+-----------------+-------------------+\n | 0x2b+7 | 1 bit | 0b0 | Blocking strategy |\n +--------+---------+-----------------+-------------------+\n | 0x2c+0 | 4 bits | 0b0110 | 8-bit block size |\n | | | | further down |\n +--------+---------+-----------------+-------------------+\n | 0x2c+4 | 4 bits | 0b1001 | Sample rate 44.1 |\n | | | | kHz |\n +--------+---------+-----------------+-------------------+\n | 0x2d+0 | 4 bits | 0b0001 | Stereo, no |\n | | | | decorrelation |\n +--------+---------+-----------------+-------------------+\n | 0x2d+4 | 3 bits | 0b100 | Bit depth 16 bits |\n +--------+---------+-----------------+-------------------+\n | 0x2d+7 | 1 bit | 0b0 | Mandatory 0 bit |\n +--------+---------+-----------------+-------------------+\n | 0x2e+0 | 1 byte | 0x00 | Frame number 0 |\n +--------+---------+-----------------+-------------------+\n | 0x2f+0 | 1 byte | 0x00 | Block size 1 |\n +--------+---------+-----------------+-------------------+\n | 0x30+0 | 1 byte | 0xbf | Frame header CRC |\n +--------+---------+-----------------+-------------------+\n\n Table 29", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "As the stream is a fixed block size stream, the number at 0x2e contains a frame number. Because the value is smaller than 128, only 1 byte is used for the encoding.", + "ja": "ストリームは固定ブロックサイズのストリームであるため、0x2Eの数にはフレーム番号が含まれています。値は128より小さいため、エンコードに使用されるのは1バイトのみです。" + }, + { + "indent": 3, + "text": "At byte 0x31, the first subframe starts, which is broken down in the following table.", + "ja": "BYTE 0x31では、最初のサブフレームが開始されます。これは、次の表で分解されます。" + }, + { + "indent": 3, + "text": " +========+=========+================+=========================+\n | Start | Length | Contents | Description |\n +========+=========+================+=========================+\n | 0x31+0 | 1 bit | 0b0 | Mandatory 0 bit |\n +--------+---------+----------------+-------------------------+\n | 0x31+1 | 6 bits | 0b000001 | Verbatim subframe |\n +--------+---------+----------------+-------------------------+\n | 0x31+7 | 1 bit | 0b1 | Wasted bits used |\n +--------+---------+----------------+-------------------------+\n | 0x32+0 | 2 bits | 0b01 | 2 wasted bits used |\n +--------+---------+----------------+-------------------------+\n | 0x32+2 | 14 bits | 0b011000, 0xfd | 14-bit unencoded sample |\n +--------+---------+----------------+-------------------------+\n\n Table 30", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "As the wasted bits flag is 1 in this subframe, a unary-coded number follows. Starting at 0x32, we see 0b01, which unary codes for 1, meaning that this subframe uses 2 wasted bits.", + "ja": "このサブフレームの無駄なビットフラグは1であるため、統一コードされた数字が続きます。0x32から、1をコードする0B01が表示されます。つまり、このサブフレームは2つの無駄なビットを使用しています。" + }, + { + "indent": 3, + "text": "As this is a verbatim subframe, the subframe only contains unencoded sample values. With a block size of 1, it contains only a single sample. The bit depth of the audio is 16 bits, but as the subframe header signals the use of 2 wasted bits, only 14 bits are stored. As no stereo decorrelation is used, a bit depth increase for the side channel is not applicable. So, the next 14 bits (starting at position 0x32+2) contain the unencoded sample coded big-endian, signed two's complement. The value reads 0b011000 11111101, or 6397. This value needs to be shifted left by 2 bits to account for the wasted bits. The value is then 0b011000 11111101 00, or 25588.", + "ja": "これは逐語的なサブフレームであるため、サブフレームにはエンコードされていないサンプル値のみが含まれています。ブロックサイズが1の場合、単一のサンプルのみが含まれています。オーディオのビット深度は16ビットですが、サブフレームヘッダーが2つの無駄なビットの使用を通知するため、14ビットのみが保存されます。ステレオの分離は使用されないため、サイドチャネルの深さの増加は適用されません。したがって、次の14ビット（位置0x32+2から始まる）には、エンコードされていないサンプルコード化されたビッグエンディアンが含まれています。値は0B011000 11111101、つまり6397を読み取ります。この値は、無駄なビットを考慮して2ビットを残してシフトする必要があります。値は0B011000 11111101 00、つまり25588です。" + }, + { + "indent": 3, + "text": "The second subframe starts at 0x34 and is broken down in the following table.", + "ja": "2番目のサブフレームは0x34から始まり、次の表で分解されます。" + }, + { + "indent": 4, + "text": " +========+=========+==============+=========================+\n | Start | Length | Contents | Description |\n +========+=========+==============+=========================+\n | 0x34+0 | 1 bit | 0b0 | Mandatory 0 bit |\n +--------+---------+--------------+-------------------------+\n | 0x34+1 | 6 bits | 0b000001 | Verbatim subframe |\n +--------+---------+--------------+-------------------------+\n | 0x34+7 | 1 bit | 0b1 | Wasted bits used |\n +--------+---------+--------------+-------------------------+\n | 0x35+0 | 4 bits | 0b0001 | 4 wasted bits used |\n +--------+---------+--------------+-------------------------+\n | 0x35+4 | 12 bits | 0b0010, 0x8b | 12-bit unencoded sample |\n +--------+---------+--------------+-------------------------+\n\n Table 31", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "The wasted bits flag is also one, but the unary-coded number that follows it is 4 bits long, indicating the use of 4 wasted bits. This means the sample is stored in 12 bits. The sample value is 0b0010 10001011, or 651. This value now has to be shifted left by 4 bits, i.e., 0b0010 10001011 0000, or 10416.", + "ja": "無駄なビットフラグも1つですが、それに続く単位コードされた数字は4ビットで、4ビットの使用を示しています。これは、サンプルが12ビットで保存されることを意味します。サンプル値は0B0010 10001011、または651です。この値は、4ビット、つまり0B0010 10001011 0000、つまり10416だけシフトする必要があります。" + }, + { + "indent": 3, + "text": "At this point, we would undo stereo decorrelation if that was applicable.", + "ja": "この時点で、それが該当する場合は、ステレオの分離を元に戻します。" + }, + { + "indent": 3, + "text": "As the last subframe ends byte-aligned, no padding bits follow it. The next 2 bytes, starting at 0x38, contain the frame CRC. As this is the only frame in the file, the file ends with the CRC.", + "ja": "最後のサブフレームがバイトアラインで終了すると、パディングビットはそれに続きません。0x38から始まる次の2バイトには、フレームCRCが含まれています。これがファイル内の唯一のフレームであるため、ファイルはCRCで終了します。" + }, + { + "indent": 3, + "text": "To validate the MD5 checksum, we line up the samples interleaved, byte-aligned, little-endian, signed two's complement. The first sample, with value 25588, translates to 0xf463, and the second sample, with value 10416, translates to 0xb028. When computing the MD5 checksum with 0xf463b028 as input, we get the MD5 checksum found in the header, so decoding was lossless.", + "ja": "MD5チェックサムを検証するために、インターリーブ、バイトアリード、リトルエンディアンのサンプルを並べ、2人の補完に署名しました。値25588の最初のサンプルは0xF463に変換され、値10416の2番目のサンプルは0xB028に変換されます。入力として0xF463B028でMD5チェックサムを計算すると、ヘッダーにMD5チェックサムが見つかりますので、デコードはロスレスでした。" + }, + { + "indent": 0, + "text": "D.2. Decoding Example 2", + "section_title": true, + "ja": "D.2. デコード例2" + }, + { + "indent": 3, + "text": "This FLAC file is larger than the first example, but still contains very little audio. The focus of this example is on decoding a subframe with a fixed predictor and a coded residual, but it also contains a very short seek table, a Vorbis comment metadata block, and a padding metadata block.", + "ja": "このFLACファイルは最初の例よりも大きいですが、オーディオはほとんど含まれていません。この例の焦点は、固定予測子とコード化された残差を使用したサブフレームのデコードにありますが、非常に短いシークテーブル、Vorbisコメントメタデータブロック、およびパディングメタデータブロックも含まれています。" + }, + { + "indent": 0, + "text": "D.2.1. Example File 2 in Hexadecimal Representation", + "section_title": true, + "ja": "D.2.1. 16進表現の例ファイル2" + }, + { + "indent": 3, + "text": "00000000: 664c 6143 0000 0022 0010 0010 fLaC...\"....\n0000000c: 0000 1700 0044 0ac4 42f0 0000 .....D..B...\n00000018: 0013 d5b0 5649 75e9 8b8d 8b93 ....VIu.....\n00000024: 0422 757b 8103 0300 0012 0000 .\"u{........\n00000030: 0000 0000 0000 0000 0000 0000 ............\n0000003c: 0000 0010 0400 003a 2000 0000 .......: ...\n00000048: 7265 6665 7265 6e63 6520 6c69 reference li\n00000054: 6246 4c41 4320 312e 332e 3320 bFLAC 1.3.3\n00000060: 3230 3139 3038 3034 0100 0000 20190804....\n0000006c: 0e00 0000 5449 544c 453d d7a9 ....TITLE=..\n00000078: d79c d795 d79d 8100 0006 0000 ............\n00000084: 0000 0000 fff8 6998 000f 9912 ......i.....\n00000090: 0867 0162 3d14 4299 8f5d f70d .g.b=.B..]..\n0000009c: 6fe0 0c17 caeb 2100 0ee7 a77a o.....!....z\n000000a8: 24a1 590c 1217 b603 097b 784f $.Y......{xO\n000000b4: aa9a 33d2 85e0 70ad 5b1b 4851 ..3...p.[.HQ\n000000c0: b401 0d99 d2cd 1a68 f1e6 b810 .......h....\n000000cc: fff8 6918 0102 a402 c382 c40b ..i.........\n000000d8: c14a 03ee 48dd 03b6 7c13 30 .J..H...|.0", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "D.2.2. Example File 2 in Binary Representation (Only Audio Frames)", + "section_title": true, + "ja": "D.2.2. バイナリ表現の例ファイル2（オーディオフレームのみ）" + }, + { + "indent": 3, + "text": "00000088: 11111111 11111000 01101001 10011000 ..i.\n0000008c: 00000000 00001111 10011001 00010010 ....\n00000090: 00001000 01100111 00000001 01100010 .g.b\n00000094: 00111101 00010100 01000010 10011001 =.B.\n00000098: 10001111 01011101 11110111 00001101 .]..\n0000009c: 01101111 11100000 00001100 00010111 o...\n000000a0: 11001010 11101011 00100001 00000000 ..!.\n000000a4: 00001110 11100111 10100111 01111010 ...z\n000000a8: 00100100 10100001 01011001 00001100 $.Y.\n000000ac: 00010010 00010111 10110110 00000011 ....\n000000b0: 00001001 01111011 01111000 01001111 .{xO\n000000b4: 10101010 10011010 00110011 11010010 ..3.\n000000b8: 10000101 11100000 01110000 10101101 ..p.\n000000bc: 01011011 00011011 01001000 01010001 [.HQ\n000000c0: 10110100 00000001 00001101 10011001 ....\n000000c4: 11010010 11001101 00011010 01101000 ...h\n000000c8: 11110001 11100110 10111000 00010000 ....\n000000cc: 11111111 11111000 01101001 00011000 ..i.\n000000d0: 00000001 00000010 10100100 00000010 ....\n000000d4: 11000011 10000010 11000100 00001011 ....\n000000d8: 11000001 01001010 00000011 11101110 .J..\n000000dc: 01001000 11011101 00000011 10110110 H...\n000000e0: 01111100 00010011 00110000 |.0", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "D.2.3. Streaminfo Metadata Block", + "section_title": true, + "ja": "D.2.3. Streaminfoメタデータブロック" + }, + { + "indent": 3, + "text": "Most of the streaminfo metadata block, including its header, is the same as in example 1, so only parts that are different are listed in the following table.", + "ja": "ヘッダーを含むStreaminfoメタデータブロックのほとんどは、例1と同じであるため、次の表に異なる部分のみがリストされています。" + }, + { + "indent": 3, + "text": " +========+=========+============+=============================+\n | Start | Length | Contents | Description |\n +========+=========+============+=============================+\n | 0x04+0 | 1 bit | 0b0 | Not the last metadata block |\n +--------+---------+------------+-----------------------------+\n | 0x08+0 | 2 bytes | 0x0010 | Min. block size 16 |\n +--------+---------+------------+-----------------------------+\n | 0x0a+0 | 2 bytes | 0x0010 | Max. block size 16 |\n +--------+---------+------------+-----------------------------+\n | 0x0c+0 | 3 bytes | 0x000017 | Min. frame size 23 bytes |\n +--------+---------+------------+-----------------------------+\n | 0x0f+0 | 3 bytes | 0x000044 | Max. frame size 68 bytes |\n +--------+---------+------------+-----------------------------+\n | 0x15+4 | 36 bits | 0b0000, | Total no. of samples 19 |\n | | | 0x00000013 | |\n +--------+---------+------------+-----------------------------+\n | 0x1a | 16 | (...) | MD5 checksum |\n | | bytes | | |\n +--------+---------+------------+-----------------------------+\n\n Table 32", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "This time, the minimum and maximum block sizes are reflected in the file: there is one block of 16 samples, and the last block (which has 3 samples) is not considered for the minimum block size. The MD5 checksum is 0xd5b0 5649 75e9 8b8d 8b93 0422 757b 8103. This will be verified at the end of this example.", + "ja": "今回は、最小および最大ブロックサイズがファイルに反映されます。16個のサンプルのブロックが1つあり、最後のブロック（3つのサンプルがある）は最小ブロックサイズでは考慮されません。MD5チェックサムは0xD5B0 5649 75E9 8B8D 8B93 0422 757B 8103です。これは、この例の最後に検証されます。" + }, + { + "indent": 0, + "text": "D.2.4. Seek Table", + "section_title": true, + "ja": "D.2.4. テーブルを探します" + }, + { + "indent": 3, + "text": "The seek table metadata block only holds one entry. It is not really useful here, as it points to the first frame, but it is enough for this example. The seek table metadata block is broken down in the following table.", + "ja": "Seek Table Metadataブロックには、1つのエントリのみが保持されます。最初のフレームを指しているため、ここでは本当に役に立ちませんが、この例には十分です。シークテーブルメタデータブロックは、次の表で分解されます。" + }, + { + "indent": 6, + "text": " +========+========+====================+================+\n | Start | Length | Contents | Description |\n +========+========+====================+================+\n | 0x2a+0 | 1 bit | 0b0 | Not the last |\n | | | | metadata block |\n +--------+--------+--------------------+----------------+\n | 0x2a+1 | 7 bits | 0b0000011 | Seek table |\n | | | | metadata block |\n +--------+--------+--------------------+----------------+\n | 0x2b+0 | 3 | 0x000012 | Length 18 |\n | | bytes | | bytes |\n +--------+--------+--------------------+----------------+\n | 0x2e+0 | 8 | 0x0000000000000000 | Seek point to |\n | | bytes | | sample 0 |\n +--------+--------+--------------------+----------------+\n | 0x36+0 | 8 | 0x0000000000000000 | Seek point to |\n | | bytes | | offset 0 |\n +--------+--------+--------------------+----------------+\n | 0x3e+0 | 2 | 0x0010 | Seek point to |\n | | bytes | | block size 16 |\n +--------+--------+--------------------+----------------+\n\n Table 33", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "D.2.5. Vorbis Comment", + "section_title": true, + "ja": "D.2.5. Vorbisコメント" + }, + { + "indent": 3, + "text": "The Vorbis comment metadata block contains the vendor string and a single comment. It is broken down in the following table.", + "ja": "Vorbisコメントメタデータブロックには、ベンダー文字列と単一のコメントが含まれています。次の表に分解されます。" + }, + { + "indent": 1, + "text": " +========+==========+============+===============================+\n | Start | Length | Contents | Description |\n +========+==========+============+===============================+\n | 0x40+0 | 1 bit | 0b0 | Not the last metadata block |\n +--------+----------+------------+-------------------------------+\n | 0x40+1 | 7 bits | 0b0000100 | Vorbis comment metadata block |\n +--------+----------+------------+-------------------------------+\n | 0x41+0 | 3 bytes | 0x00003a | Length 58 bytes |\n +--------+----------+------------+-------------------------------+\n | 0x44+0 | 4 bytes | 0x20000000 | Vendor string length 32 bytes |\n +--------+----------+------------+-------------------------------+\n | 0x48+0 | 32 bytes | (...) | Vendor string |\n +--------+----------+------------+-------------------------------+\n | 0x68+0 | 4 bytes | 0x01000000 | Number of fields 1 |\n +--------+----------+------------+-------------------------------+\n | 0x6c+0 | 4 bytes | 0x0e000000 | Field length 14 bytes |\n +--------+----------+------------+-------------------------------+\n | 0x70+0 | 14 bytes | (...) | Field contents |\n +--------+----------+------------+-------------------------------+\n\n Table 34", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "The vendor string is reference libFLAC 1.3.3 20190804, and the field contents of the only field is", + "ja": "ベンダー文字列はリファレンスlibflac 1.3.3 20190804であり、フィールドの唯一のフィールドの内容は" + }, + { + "indent": 3, + "text": "TITLE=שלום", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "where in direction of reading, the sequence of characters forming the field content is: \"ש\" (HEBREW LETTER SHIN, U+05E9), \"ל\" (HEBREW LETTER LAMED, U+05DC), \"ו\" (HEBREW LETTER VAV, U+05D5), \"ם\" (HEBREW LETTER FINAL MEM, U+05DD).", + "ja": "読み方の方向では、フィールドコンテンツを形成する文字のシーケンスは、「ש」（ヘブライ文字Shin、U+05e9）、「ל」（ヘブライ文字leall、u+05dc）、 \"וו\"（ヘブライ文字vav、u+05d5）、「ם」（ヘブライ文字最終mem、u+05dd）。" + }, + { + "indent": 3, + "text": "The Vorbis comment field is 14 bytes but only 10 characters in size, because it contains four 2-byte characters.", + "ja": "Vorbisコメントフィールドは14バイトですが、4バイト文字が4つ含まれているため、サイズは10文字のみです。" + }, + { + "indent": 0, + "text": "D.2.6. Padding", + "section_title": true, + "ja": "D.2.6. パディング" + }, + { + "indent": 3, + "text": "The last metadata block is a (very short) padding block.", + "ja": "最後のメタデータブロックは、（非常に短い）パディングブロックです。" + }, + { + "indent": 3, + "text": " +========+=========+================+========================+\n | Start | Length | Contents | Description |\n +========+=========+================+========================+\n | 0x7e+0 | 1 bit | 0b1 | Last metadata block |\n +--------+---------+----------------+------------------------+\n | 0x7e+1 | 7 bits | 0b0000001 | Padding metadata block |\n +--------+---------+----------------+------------------------+\n | 0x7f+0 | 3 bytes | 0x000006 | Length 6 byte |\n +--------+---------+----------------+------------------------+\n | 0x82+0 | 6 bytes | 0x000000000000 | Padding bytes |\n +--------+---------+----------------+------------------------+\n\n Table 35", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "D.2.7. First Audio Frame", + "section_title": true, + "ja": "D.2.7. 最初のオーディオフレーム" + }, + { + "indent": 3, + "text": "The frame header starts at position 0x88 and is broken down in the following table.", + "ja": "フレームヘッダーは位置0x88から始まり、次の表で分解されます。" + }, + { + "indent": 5, + "text": " +========+=========+=================+===================+\n | Start | Length | Contents | Description |\n +========+=========+=================+===================+\n | 0x88+0 | 15 bits | 0xff, 0b1111100 | Frame sync |\n +--------+---------+-----------------+-------------------+\n | 0x89+7 | 1 bit | 0b0 | Blocking strategy |\n +--------+---------+-----------------+-------------------+\n | 0x8a+0 | 4 bits | 0b0110 | 8-bit block size |\n | | | | further down |\n +--------+---------+-----------------+-------------------+\n | 0x8a+4 | 4 bits | 0b1001 | Sample rate 44.1 |\n | | | | kHz |\n +--------+---------+-----------------+-------------------+\n | 0x8b+0 | 4 bits | 0b1001 | Side-right stereo |\n +--------+---------+-----------------+-------------------+\n | 0x8b+4 | 3 bits | 0b100 | Bit depth 16 bit |\n +--------+---------+-----------------+-------------------+\n | 0x8b+7 | 1 bit | 0b0 | Mandatory 0 bit |\n +--------+---------+-----------------+-------------------+\n | 0x8c+0 | 1 byte | 0x00 | Frame number 0 |\n +--------+---------+-----------------+-------------------+\n | 0x8d+0 | 1 byte | 0x0f | Block size 16 |\n +--------+---------+-----------------+-------------------+\n | 0x8e+0 | 1 byte | 0x99 | Frame header CRC |\n +--------+---------+-----------------+-------------------+\n\n Table 36", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "The first subframe starts at byte 0x8f, and it is broken down in the following table, excluding the coded residual. As this subframe codes for a side channel, the bit depth is increased by 1 bit from 16 bits to 17 bits. This is most clearly present in the unencoded warm-up sample.", + "ja": "最初のサブフレームはBYTE 0x8Fで始まり、コード化された残差を除き、次の表で分解されます。このサブフレームがサイドチャネルをコードするため、ビットの深さは16ビットから17ビットから1ビットから1ビット増加します。これは、エンコードされていないウォームアップサンプルに最も明確に存在します。" + }, + { + "indent": 3, + "text": " +========+=========+=============+===========================+\n | Start | Length | Contents | Description |\n +========+=========+=============+===========================+\n | 0x8f+0 | 1 bit | 0b0 | Mandatory 0 bit |\n +--------+---------+-------------+---------------------------+\n | 0x8f+1 | 6 bits | 0b001001 | Fixed subframe, 1st order |\n +--------+---------+-------------+---------------------------+\n | 0x8f+7 | 1 bit | 0b0 | No wasted bits used |\n +--------+---------+-------------+---------------------------+\n | 0x90+0 | 17 bits | 0x0867, 0b0 | Unencoded warm-up sample |\n +--------+---------+-------------+---------------------------+\n\n Table 37", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "The coded residual is broken down in the following table. All quotients are unary coded, and all remainders are stored unencoded with a number of bits specified by the Rice parameter.", + "ja": "コード化された残差は、次の表に分解されます。すべての商は単位コード化されており、すべての残りは、イネパラメーターによって指定された多数のビットでエンコードされていない保存されます。" + }, + { + "indent": 7, + "text": " +========+========+=================+=================+\n | Start | Length | Contents | Description |\n +========+========+=================+=================+\n | 0x92+1 | 2 bits | 0b00 | Rice code with |\n | | | | 4-bit parameter |\n +--------+--------+-----------------+-----------------+\n | 0x92+3 | 4 bits | 0b0000 | Partition order |\n | | | | 0 |\n +--------+--------+-----------------+-----------------+\n | 0x92+7 | 4 bits | 0b1011 | Rice parameter |\n | | | | 11 |\n +--------+--------+-----------------+-----------------+\n | 0x93+3 | 4 bits | 0b0001 | Quotient 3 |\n +--------+--------+-----------------+-----------------+\n | 0x93+7 | 11 | 0b00011110100 | Remainder 244 |\n | | bits | | |\n +--------+--------+-----------------+-----------------+\n | 0x95+2 | 2 bits | 0b01 | Quotient 1 |\n +--------+--------+-----------------+-----------------+\n | 0x95+4 | 11 | 0b01000100001 | Remainder 545 |\n | | bits | | |\n +--------+--------+-----------------+-----------------+\n | 0x96+7 | 2 bits | 0b01 | Quotient 1 |\n +--------+--------+-----------------+-----------------+\n | 0x97+1 | 11 | 0b00110011000 | Remainder 408 |\n | | bits | | |\n +--------+--------+-----------------+-----------------+\n | 0x98+4 | 1 bit | 0b1 | Quotient 0 |\n +--------+--------+-----------------+-----------------+\n | 0x98+5 | 11 | 0b11101011101 | Remainder 1885 |\n | | bits | | |\n +--------+--------+-----------------+-----------------+\n | 0x9a+0 | 1 bit | 0b1 | Quotient 0 |\n +--------+--------+-----------------+-----------------+\n | 0x9a+1 | 11 | 0b11101110000 | Remainder 1904 |\n | | bits | | |\n +--------+--------+-----------------+-----------------+\n | 0x9b+4 | 1 bit | 0b1 | Quotient 0 |\n +--------+--------+-----------------+-----------------+\n | 0x9b+5 | 11 | 0b10101101111 | Remainder 1391 |\n | | bits | | |\n +--------+--------+-----------------+-----------------+\n | 0x9d+0 | 1 bit | 0b1 | Quotient 0 |\n +--------+--------+-----------------+-----------------+\n | 0x9d+1 | 11 | 0b11000000000 | Remainder 1536 |\n | | bits | | |\n +--------+--------+-----------------+-----------------+\n | 0x9e+4 | 1 bit | 0b1 | Quotient 0 |\n +--------+--------+-----------------+-----------------+\n | 0x9e+5 | 11 | 0b10000010111 | Remainder 1047 |\n | | bits | | |\n +--------+--------+-----------------+-----------------+\n | 0xa0+0 | 1 bit | 0b1 | Quotient 0 |\n +--------+--------+-----------------+-----------------+\n | 0xa0+1 | 11 | 0b10010101110 | Remainder 1198 |\n | | bits | | |\n +--------+--------+-----------------+-----------------+\n | 0xa1+4 | 1 bit | 0b1 | Quotient 0 |\n +--------+--------+-----------------+-----------------+\n | 0xa1+5 | 11 | 0b01100100001 | Remainder 801 |\n | | bits | | |\n +--------+--------+-----------------+-----------------+\n | 0xa3+0 | 13 | 0b0000000000001 | Quotient 12 |\n | | bits | | |\n +--------+--------+-----------------+-----------------+\n | 0xa4+5 | 11 | 0b11011100111 | Remainder 1767 |\n | | bits | | |\n +--------+--------+-----------------+-----------------+\n | 0xa6+0 | 1 bit | 0b1 | Quotient 0 |\n +--------+--------+-----------------+-----------------+\n | 0xa6+1 | 11 | 0b01001110111 | Remainder 631 |\n | | bits | | |\n +--------+--------+-----------------+-----------------+\n | 0xa7+4 | 1 bit | 0b1 | Quotient 0 |\n +--------+--------+-----------------+-----------------+\n | 0xa7+5 | 11 | 0b01000100100 | Remainder 548 |\n | | bits | | |\n +--------+--------+-----------------+-----------------+\n | 0xa9+0 | 1 bit | 0b1 | Quotient 0 |\n +--------+--------+-----------------+-----------------+\n | 0xa9+1 | 11 | 0b01000010101 | Remainder 533 |\n | | bits | | |\n +--------+--------+-----------------+-----------------+\n | 0xaa+4 | 1 bit | 0b1 | Quotient 0 |\n +--------+--------+-----------------+-----------------+\n | 0xaa+5 | 11 | 0b00100001100 | Remainder 268 |\n | | bits | | |\n +--------+--------+-----------------+-----------------+\n\n Table 38", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "At this point, the decoder should know it is done decoding the coded residual, as it received 16 samples: 1 warm-up sample and 15 residual samples. Each residual sample can be calculated from the quotient and remainder and from undoing the zigzag encoding. For example, the value of the first zigzag-encoded residual sample is 3 * 2^11 + 244 = 6388. As this is an even number, the zigzag encoding is undone by dividing by 2; the residual sample value is 3194. This is done for all residual samples in the next table.", + "ja": "この時点で、デコーダーは16のサンプルを受け取ったため、コード化された残差を解読していることを知っている必要があります：1つのウォームアップサンプルと15の残留サンプル。各残差サンプルは、商と残りから、Zigzagエンコーディングを元に戻すことから計算できます。たとえば、最初のジグザグエンコード残差サンプルの値は3 * 2^11 + 244 = 6388です。これは偶数であるため、ジグザグエンコーディングは2で除算することで元に戻されます。残差サンプル値は3194です。これは、次の表のすべての残差サンプルに対して行われます。" + }, + { + "indent": 2, + "text": " +==========+===========+================+=======================+\n | Quotient | Remainder | Zigzag Encoded | Residual Sample Value |\n +==========+===========+================+=======================+\n | 3 | 244 | 6388 | 3194 |\n +----------+-----------+----------------+-----------------------+\n | 1 | 545 | 2593 | -1297 |\n +----------+-----------+----------------+-----------------------+\n | 1 | 408 | 2456 | 1228 |\n +----------+-----------+----------------+-----------------------+\n | 0 | 1885 | 1885 | -943 |\n +----------+-----------+----------------+-----------------------+\n | 0 | 1904 | 1904 | 952 |\n +----------+-----------+----------------+-----------------------+\n | 0 | 1391 | 1391 | -696 |\n +----------+-----------+----------------+-----------------------+\n | 0 | 1536 | 1536 | 768 |\n +----------+-----------+----------------+-----------------------+\n | 0 | 1047 | 1047 | -524 |\n +----------+-----------+----------------+-----------------------+\n | 0 | 1198 | 1198 | 599 |\n +----------+-----------+----------------+-----------------------+\n | 0 | 801 | 801 | -401 |\n +----------+-----------+----------------+-----------------------+\n | 12 | 1767 | 26343 | -13172 |\n +----------+-----------+----------------+-----------------------+\n | 0 | 631 | 631 | -316 |\n +----------+-----------+----------------+-----------------------+\n | 0 | 548 | 548 | 274 |\n +----------+-----------+----------------+-----------------------+\n | 0 | 533 | 533 | -267 |\n +----------+-----------+----------------+-----------------------+\n | 0 | 268 | 268 | 134 |\n +----------+-----------+----------------+-----------------------+\n\n Table 39", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "In this case, using a Rice code is more efficient than storing values unencoded. The Rice code (excluding the partition order and parameter) is 199 bits in length. The largest residual value (-13172) would need 15 bits to be stored unencoded, so storing all 15 samples with 15 bits results in a sequence with a length of 225 bits.", + "ja": "この場合、稲法を使用することは、エンコードされていない値を保存するよりも効率的です。稲法（パーティションの順序とパラメーターを除く）の長さは199ビットです。最大の残留値（-13172）は、エンコードなしで15ビットを保存する必要があるため、15ビットの15サンプルすべてを保存すると、長さ225ビットのシーケンスになります。" + }, + { + "indent": 3, + "text": "The next step is using the predictor and the residuals to restore the sample values. As this subframe uses a fixed predictor with order 1, the residual value is added to the value of the previous sample.", + "ja": "次のステップは、予測子と残差を使用してサンプル値を復元することです。このサブフレームは、順序1で固定予測子を使用するため、残差は前のサンプルの値に追加されます。" + }, + { + "indent": 20, + "text": " +===========+==============+\n | Residual | Sample Value |\n +===========+==============+\n | (warm-up) | 4302 |\n +-----------+--------------+\n | 3194 | 7496 |\n +-----------+--------------+\n | -1297 | 6199 |\n +-----------+--------------+\n | 1228 | 7427 |\n +-----------+--------------+\n | -943 | 6484 |\n +-----------+--------------+\n | 952 | 7436 |\n +-----------+--------------+\n | -696 | 6740 |\n +-----------+--------------+\n | 768 | 7508 |\n +-----------+--------------+\n | -524 | 6984 |\n +-----------+--------------+\n | 599 | 7583 |\n +-----------+--------------+\n | -401 | 7182 |\n +-----------+--------------+\n | -13172 | -5990 |\n +-----------+--------------+\n | -316 | -6306 |\n +-----------+--------------+\n | 274 | -6032 |\n +-----------+--------------+\n | -267 | -6299 |\n +-----------+--------------+\n | 134 | -6165 |\n +-----------+--------------+\n\n Table 40", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "With this, the decoding of the first subframe is complete. The decoding of the second subframe is very similar, as it also uses a fixed predictor of order 1. This is left as an exercise for the reader; the results are in the next table. The next step is undoing stereo decorrelation, which is done in the following table. As the stereo decorrelation is side-right, the samples in the right channel come directly from the second subframe, while the samples in the left channel are found by adding the values of both subframes for each sample.", + "ja": "これにより、最初のサブフレームのデコードが完了します。2番目のサブフレームのデコードは、注文1の固定予測因子も使用するため、非常に似ています。これは、読者の演習として残されています。結果は次の表にあります。次のステップは、次の表で行われるステレオ分離を元に戻すことです。ステレオの分離はサイドロイトであるため、右チャネルのサンプルは2番目のサブフレームから直接送られますが、左チャネルのサンプルは、各サンプルの両方のサブフレームの値を追加することで見つかります。" + }, + { + "indent": 12, + "text": " +============+============+========+=======+\n | Subframe 1 | Subframe 2 | Left | Right |\n +============+============+========+=======+\n | 4302 | 6070 | 10372 | 6070 |\n +------------+------------+--------+-------+\n | 7496 | 10545 | 18041 | 10545 |\n +------------+------------+--------+-------+\n | 6199 | 8743 | 14942 | 8743 |\n +------------+------------+--------+-------+\n | 7427 | 10449 | 17876 | 10449 |\n +------------+------------+--------+-------+\n | 6484 | 9143 | 15627 | 9143 |\n +------------+------------+--------+-------+\n | 7436 | 10463 | 17899 | 10463 |\n +------------+------------+--------+-------+\n | 6740 | 9502 | 16242 | 9502 |\n +------------+------------+--------+-------+\n | 7508 | 10569 | 18077 | 10569 |\n +------------+------------+--------+-------+\n | 6984 | 9840 | 16824 | 9840 |\n +------------+------------+--------+-------+\n | 7583 | 10680 | 18263 | 10680 |\n +------------+------------+--------+-------+\n | 7182 | 10113 | 17295 | 10113 |\n +------------+------------+--------+-------+\n | -5990 | -8428 | -14418 | -8428 |\n +------------+------------+--------+-------+\n | -6306 | -8895 | -15201 | -8895 |\n +------------+------------+--------+-------+\n | -6032 | -8476 | -14508 | -8476 |\n +------------+------------+--------+-------+\n | -6299 | -8896 | -15195 | -8896 |\n +------------+------------+--------+-------+\n | -6165 | -8653 | -14818 | -8653 |\n +------------+------------+--------+-------+\n\n Table 41", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "As the second subframe ends byte-aligned, no padding bits follow it. Finally, the last 2 bytes of the frame contain the frame CRC.", + "ja": "2番目のサブフレームがバイトアラインを終了すると、パディングビットはそれに続いていません。最後に、フレームの最後の2バイトにはフレームCRCが含まれています。" + }, + { + "indent": 0, + "text": "D.2.8. Second Audio Frame", + "section_title": true, + "ja": "D.2.8. 2番目のオーディオフレーム" + }, + { + "indent": 3, + "text": "The second audio frame is very similar to the frame decoded in the first example, but this time, 3 samples (not 1) are present.", + "ja": "2番目のオーディオフレームは、最初の例でデコードされたフレームに非常に似ていますが、今回は3つのサンプル（1ではない）が存在します。" + }, + { + "indent": 3, + "text": "The frame header starts at position 0xcc and is broken down in the following table.", + "ja": "フレームヘッダーは位置0xccで始まり、次の表で分解されます。" + }, + { + "indent": 5, + "text": " +========+=========+=================+===================+\n | Start | Length | Contents | Description |\n +========+=========+=================+===================+\n | 0xcc+0 | 15 bits | 0xff, 0b1111100 | Frame sync |\n +--------+---------+-----------------+-------------------+\n | 0xcd+7 | 1 bit | 0b0 | Blocking strategy |\n +--------+---------+-----------------+-------------------+\n | 0xce+0 | 4 bits | 0b0110 | 8-bit block size |\n | | | | further down |\n +--------+---------+-----------------+-------------------+\n | 0xce+4 | 4 bits | 0b1001 | Sample rate 44.1 |\n | | | | kHz |\n +--------+---------+-----------------+-------------------+\n | 0xcf+0 | 4 bits | 0b0001 | Stereo, no |\n | | | | decorrelation |\n +--------+---------+-----------------+-------------------+\n | 0xcf+4 | 3 bits | 0b100 | Bit depth 16 bits |\n +--------+---------+-----------------+-------------------+\n | 0xcf+7 | 1 bit | 0b0 | Mandatory 0 bit |\n +--------+---------+-----------------+-------------------+\n | 0xd0+0 | 1 byte | 0x01 | Frame number 1 |\n +--------+---------+-----------------+-------------------+\n | 0xd1+0 | 1 byte | 0x02 | Block size 3 |\n +--------+---------+-----------------+-------------------+\n | 0xd2+0 | 1 byte | 0xa4 | Frame header CRC |\n +--------+---------+-----------------+-------------------+\n\n Table 42", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "The first subframe starts at 0xd3+0 and is broken down in the following table.", + "ja": "最初のサブフレームは0xD3+0から始まり、次の表で分解されます。" + }, + { + "indent": 6, + "text": " +========+=========+==========+=========================+\n | Start | Length | Contents | Description |\n +========+=========+==========+=========================+\n | 0xd3+0 | 1 bit | 0b0 | Mandatory 0 bit |\n +--------+---------+----------+-------------------------+\n | 0xd3+1 | 6 bits | 0b000001 | Verbatim subframe |\n +--------+---------+----------+-------------------------+\n | 0xd3+7 | 1 bit | 0b0 | No wasted bits used |\n +--------+---------+----------+-------------------------+\n | 0xd4+0 | 16 bits | 0xc382 | 16-bit unencoded sample |\n +--------+---------+----------+-------------------------+\n | 0xd6+0 | 16 bits | 0xc40b | 16-bit unencoded sample |\n +--------+---------+----------+-------------------------+\n | 0xd8+0 | 16 bits | 0xc14a | 16-bit unencoded sample |\n +--------+---------+----------+-------------------------+\n\n Table 43", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "The second subframe starts at 0xda+0 and is broken down in the following table.", + "ja": "2番目のサブフレームは0xDa+0から始まり、次の表で分解されます。" + }, + { + "indent": 1, + "text": " +========+=========+===================+=========================+\n | Start | Length | Contents | Description |\n +========+=========+===================+=========================+\n | 0xda+0 | 1 bit | 0b0 | Mandatory 0 bit |\n +--------+---------+-------------------+-------------------------+\n | 0xda+1 | 6 bits | 0b000001 | Verbatim subframe |\n +--------+---------+-------------------+-------------------------+\n | 0xda+7 | 1 bit | 0b1 | Wasted bits used |\n +--------+---------+-------------------+-------------------------+\n | 0xdb+0 | 1 bit | 0b1 | 1 wasted bit used |\n +--------+---------+-------------------+-------------------------+\n | 0xdb+1 | 15 bits | 0b110111001001000 | 15-bit unencoded sample |\n +--------+---------+-------------------+-------------------------+\n | 0xdd+0 | 15 bits | 0b110111010000001 | 15-bit unencoded sample |\n +--------+---------+-------------------+-------------------------+\n | 0xde+7 | 15 bits | 0b110110110011111 | 15-bit unencoded sample |\n +--------+---------+-------------------+-------------------------+\n\n Table 44", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "As this subframe uses wasted bits, the 15-bit unencoded samples need to be shifted left by 1 bit. For example, sample 1 is stored as -4536 and becomes -9072 after shifting left 1 bit.", + "ja": "このサブフレームは無駄なビットを使用するため、15ビットの非エンエンコードサンプルを1ビットでシフトする必要があります。たとえば、サンプル1は-4536として保存され、左1ビットをシフトした後に-9072になります。" + }, + { + "indent": 3, + "text": "As the last subframe does not end on byte alignment, 2 padding bits are added before the 2-byte frame CRC, which follows at 0xe1+0.", + "ja": "最後のサブフレームはバイトアラインメントで終了しないため、2バイトフレームCRCの前に2つのパディングビットが追加されます。これは0xe1+0です。" + }, + { + "indent": 0, + "text": "D.2.9. MD5 Checksum Verification", + "section_title": true, + "ja": "D.2.9. MD5チェックサム検証" + }, + { + "indent": 3, + "text": "All samples in the file have been decoded, and we can now verify the MD5 checksum. All sample values must be interleaved and stored signed coded little-endian. The result of this follows in groups of 12 samples (i.e., 6 interchannel samples) per line.", + "ja": "ファイル内のすべてのサンプルがデコードされており、MD5チェックサムを確認できるようになりました。すべてのサンプル値はインターリーブし、署名されたコード付きリトルエンディアンを保存する必要があります。これの結果は、1行あたり12のサンプル（つまり、6つのインターチャネルサンプル）のグループになります。" + }, + { + "indent": 3, + "text": "0x8428 B617 7946 3129 5E3A 2722 D445 D128 0B3D B723 EB45 DF28\n0x723f 1E25 9D46 4929 B841 7026 5747 B829 8F43 8127 AEC7 14DF\n0x9FC4 41DD 54C7 E4DE A5C4 40DD 1EC6 33DE 82C3 90DC 0BC4 02DD\n0x4AC1 3EDB", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "The MD5 checksum of this is indeed the same as the one found in the streaminfo metadata block.", + "ja": "これのMD5チェックサムは、確かにStreaminfoメタデータブロックに見られるものと同じです。" + }, + { + "indent": 0, + "text": "D.3. Decoding Example 3", + "section_title": true, + "ja": "D.3. デコード例3" + }, + { + "indent": 3, + "text": "This example is once again a very short FLAC file. The focus of this example is on decoding a subframe with a linear predictor and a coded residual with more than one partition.", + "ja": "この例は、再び非常に短いFLACファイルです。この例の焦点は、線形予測因子と複数のパーティションを備えたコード化された残差を備えたサブフレームをデコードすることです。" + }, + { + "indent": 0, + "text": "D.3.1. Example File 3 in Hexadecimal Representation", + "section_title": true, + "ja": "D.3.1. 16進表現の例ファイル3" + }, + { + "indent": 3, + "text": "00000000: 664c 6143 8000 0022 1000 1000 fLaC...\"....\n0000000c: 0000 1f00 001f 07d0 0070 0000 .........p..\n00000018: 0018 f8f9 e396 f5cb cfc6 dc80 ............\n00000024: 7f99 7790 6b32 fff8 6802 0017 ..w.k2..h...\n00000030: e944 004f 6f31 3d10 47d2 27cb .D.Oo1=.G.'.\n0000003c: 6d09 0831 452b dc28 2222 8057 m..1E+.(\"\".W\n00000048: a3 .", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "D.3.2. Example File 3 in Binary Representation (Only Audio Frame)", + "section_title": true, + "ja": "D.3.2. バイナリ表現の例ファイル3（オーディオフレームのみ）" + }, + { + "indent": 3, + "text": "0000002a: 11111111 11111000 01101000 00000010 ..h.\n0000002e: 00000000 00010111 11101001 01000100 ...D\n00000032: 00000000 01001111 01101111 00110001 .Oo1\n00000036: 00111101 00010000 01000111 11010010 =.G.\n0000003a: 00100111 11001011 01101101 00001001 '.m.\n0000003e: 00001000 00110001 01000101 00101011 .1E+\n00000042: 11011100 00101000 00100010 00100010 .(\"\"\n00000046: 10000000 01010111 10100011 .W.", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "D.3.3. Streaminfo Metadata Block", + "section_title": true, + "ja": "D.3.3. Streaminfoメタデータブロック" + }, + { + "indent": 3, + "text": "Most of the streaminfo metadata block, including its header, is the same as in example 1, so only parts that are different are listed in the following table.", + "ja": "ヘッダーを含むStreaminfoメタデータブロックのほとんどは、例1と同じであるため、次の表に異なる部分のみがリストされています。" + }, + { + "indent": 0, + "text": "+========+==========+====================+==========================+\n| Start | Length | Contents | Description |\n+========+==========+====================+==========================+\n| 0x0c+0 | 3 bytes | 0x00001f | Min. frame size 31 bytes |\n+--------+----------+--------------------+--------------------------+\n| 0x0f+0 | 3 bytes | 0x00001f | Max. frame size 31 bytes |\n+--------+----------+--------------------+--------------------------+\n| 0x12+0 | 20 bits | 0x07d0, 0x0000 | Sample rate 32000 hertz |\n+--------+----------+--------------------+--------------------------+\n| 0x14+4 | 3 bits | 0b000 | 1 channel |\n+--------+----------+--------------------+--------------------------+\n| 0x14+7 | 5 bits | 0b00111 | Sample bit depth 8 bits |\n+--------+----------+--------------------+--------------------------+\n| 0x15+4 | 36 bits | 0b0000, 0x00000018 | Total no. of samples 24 |\n+--------+----------+--------------------+--------------------------+\n| 0x1a | 16 | (...) | MD5 checksum |\n| | bytes | | |\n+--------+----------+--------------------+--------------------------+\n\n Table 45", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "D.3.4. Audio Frame", + "section_title": true, + "ja": "D.3.4. オーディオフレーム" + }, + { + "indent": 3, + "text": "The frame header starts at position 0x2a and is broken down in the following table.", + "ja": "フレームヘッダーは位置0x2aから始まり、次の表で分解されます。" + }, + { + "indent": 5, + "text": " +========+=========+=================+===================+\n | Start | Length | Contents | Description |\n +========+=========+=================+===================+\n | 0x2a+0 | 15 bits | 0xff, 0b1111100 | Frame sync |\n +--------+---------+-----------------+-------------------+\n | 0x2b+7 | 1 bit | 0b0 | blocking strategy |\n +--------+---------+-----------------+-------------------+\n | 0x2c+0 | 4 bits | 0b0110 | 8-bit block size |\n | | | | further down |\n +--------+---------+-----------------+-------------------+\n | 0x2c+4 | 4 bits | 0b1000 | Sample rate 32 |\n | | | | kHz |\n +--------+---------+-----------------+-------------------+\n | 0x2d+0 | 4 bits | 0b0000 | Mono audio (1 |\n | | | | channel) |\n +--------+---------+-----------------+-------------------+\n | 0x2d+4 | 3 bits | 0b001 | Bit depth 8 bits |\n +--------+---------+-----------------+-------------------+\n | 0x2d+7 | 1 bit | 0b0 | Mandatory 0 bit |\n +--------+---------+-----------------+-------------------+\n | 0x2e+0 | 1 byte | 0x00 | Frame number 0 |\n +--------+---------+-----------------+-------------------+\n | 0x2f+0 | 1 byte | 0x17 | Block size 24 |\n +--------+---------+-----------------+-------------------+\n | 0x30+0 | 1 byte | 0xe9 | Frame header CRC |\n +--------+---------+-----------------+-------------------+\n\n Table 46", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "The first and only subframe starts at byte 0x31. It is broken down in the following table, without the coded residual.", + "ja": "最初の唯一のサブフレームは、BYTE 0x31で始まります。コード化された残差なしで、次の表に分解されます。" + }, + { + "indent": 8, + "text": " +========+========+==========+=====================+\n | Start | Length | Contents | Description |\n +========+========+==========+=====================+\n | 0x31+0 | 1 bit | 0b0 | Mandatory 0 bit |\n +--------+--------+----------+---------------------+\n | 0x31+1 | 6 bits | 0b100010 | Linear prediction |\n | | | | subframe, 3rd order |\n +--------+--------+----------+---------------------+\n | 0x31+7 | 1 bit | 0b0 | No wasted bits used |\n +--------+--------+----------+---------------------+\n | 0x32+0 | 8 bits | 0x00 | Unencoded warm-up |\n | | | | sample 0 |\n +--------+--------+----------+---------------------+\n | 0x33+0 | 8 bits | 0x4f | Unencoded warm-up |\n | | | | sample 79 |\n +--------+--------+----------+---------------------+\n | 0x34+0 | 8 bits | 0x6f | Unencoded warm-up |\n | | | | sample 111 |\n +--------+--------+----------+---------------------+\n | 0x35+0 | 4 bits | 0b0011 | Coefficient |\n | | | | precision 4 bit |\n +--------+--------+----------+---------------------+\n | 0x35+4 | 5 bits | 0b00010 | Prediction right |\n | | | | shift 2 |\n +--------+--------+----------+---------------------+\n | 0x36+1 | 4 bits | 0b0111 | Predictor |\n | | | | coefficient 7 |\n +--------+--------+----------+---------------------+\n | 0x36+5 | 4 bits | 0b1010 | Predictor |\n | | | | coefficient -6 |\n +--------+--------+----------+---------------------+\n | 0x37+1 | 4 bits | 0b0010 | Predictor |\n | | | | coefficient 2 |\n +--------+--------+----------+---------------------+\n\n Table 47", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "The data stream continues with the coded residual, which is broken down in the following table. Residual partitions 3 and 4 are left as an exercise for the reader.", + "ja": "データストリームは、次の表に分解されているコード化された残差で続きます。残留パーティション3と4は、読者のための演習として残されています。" + }, + { + "indent": 0, + "text": "+========+========+==========+======================================+\n| Start | Length | Contents | Description |\n+========+========+==========+======================================+\n| 0x37+5 | 2 bits | 0b00 | Rice-coded residual, |\n| | | | 4-bit parameter |\n+--------+--------+----------+--------------------------------------+\n| 0x37+7 | 4 bits | 0b0010 | Partition order 2 |\n+--------+--------+----------+--------------------------------------+\n| 0x38+3 | 4 bits | 0b0011 | Rice parameter 3 |\n+--------+--------+----------+--------------------------------------+\n| 0x38+7 | 1 bit | 0b1 | Quotient 0 |\n+--------+--------+----------+--------------------------------------+\n| 0x39+0 | 3 bits | 0b110 | Remainder 6 |\n+--------+--------+----------+--------------------------------------+\n| 0x39+3 | 1 bit | 0b1 | Quotient 0 |\n+--------+--------+----------+--------------------------------------+\n| 0x39+4 | 3 bits | 0b001 | Remainder 1 |\n+--------+--------+----------+--------------------------------------+\n| 0x39+7 | 4 bits | 0b0001 | Quotient 3 |\n+--------+--------+----------+--------------------------------------+\n| 0x3a+3 | 3 bits | 0b001 | Remainder 1 |\n+--------+--------+----------+--------------------------------------+\n| 0x3a+6 | 4 bits | 0b1111 | No Rice parameter, |\n| | | | escape code |\n+--------+--------+----------+--------------------------------------+\n| 0x3b+2 | 5 bits | 0b00101 | Partition encoded |\n| | | | with 5 bits |\n+--------+--------+----------+--------------------------------------+\n| 0x3b+7 | 5 bits | 0b10110 | Residual -10 |\n+--------+--------+----------+--------------------------------------+\n| 0x3c+4 | 5 bits | 0b11010 | Residual -6 |\n+--------+--------+----------+--------------------------------------+\n| 0x3d+1 | 5 bits | 0b00010 | Residual 2 |\n+--------+--------+----------+--------------------------------------+\n| 0x3d+6 | 5 bits | 0b01000 | Residual 8 |\n+--------+--------+----------+--------------------------------------+\n| 0x3e+3 | 5 bits | 0b01000 | Residual 8 |\n+--------+--------+----------+--------------------------------------+\n| 0x3f+0 | 5 bits | 0b00110 | Residual 6 |\n+--------+--------+----------+--------------------------------------+\n| 0x3f+5 | 4 bits | 0b0010 | Rice parameter 2 |\n+--------+--------+----------+--------------------------------------+\n| 0x40+1 | 22 | (...) | Residual partition 3 |\n| | bits | | |\n+--------+--------+----------+--------------------------------------+\n| 0x42+7 | 4 bits | 0b0001 | Rice parameter 1 |\n+--------+--------+----------+--------------------------------------+\n| 0x43+3 | 23 | (...) | Residual partition 4 |\n| | bits | | |\n+--------+--------+----------+--------------------------------------+\n\n Table 48", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "The frame ends with 6 padding bits and a 2-byte frame CRC.", + "ja": "フレームは、6つのパディングビットと2バイトのフレームCRCで終わります。" + }, + { + "indent": 3, + "text": "To decode this subframe, 21 predictions have to be calculated and added to their corresponding residuals. This is a sequential process: as each prediction uses previous samples, it is not possible to start this decoding halfway through a subframe or decode a subframe with parallel threads.", + "ja": "このサブフレームをデコードするには、21の予測を計算し、対応する残差に追加する必要があります。これはシーケンシャルプロセスです。各予測は以前のサンプルを使用するため、サブフレームの途中でこのデコードを開始したり、並列スレッドでサブフレームをデコードすることはできません。" + }, + { + "indent": 3, + "text": "The following table breaks down the calculation for each sample. For example, the predictor without shift value of row 4 is found by applying the predictor with the three warm-up samples: 7*111 - 6*79 + 2*0 = 303. This value is then shifted right by 2 bits: 303 >> 2 = 75. Then, the decoded residual sample is added: 75 + 3 = 78.", + "ja": "次の表は、各サンプルの計算を分解します。たとえば、行4のシフト値のない予測因子は、3つのウォームアップサンプルで予測子を適用することにより見つかります：7*111-6*79 + 2*0 = 303。この値は2ビットの右にシフトされます：303>> 2 =75。その後、デコードされた残留サンプルが追加されます：75 + 3 = 78。" + }, + { + "indent": 3, + "text": " +===========+=====================+===========+==============+\n | Residual | Predictor w/o Shift | Predictor | Sample Value |\n +===========+=====================+===========+==============+\n | (warm-up) | N/A | N/A | 0 |\n +-----------+---------------------+-----------+--------------+\n | (warm-up) | N/A | N/A | 79 |\n +-----------+---------------------+-----------+--------------+\n | (warm-up) | N/A | N/A | 111 |\n +-----------+---------------------+-----------+--------------+\n | 3 | 303 | 75 | 78 |\n +-----------+---------------------+-----------+--------------+\n | -1 | 38 | 9 | 8 |\n +-----------+---------------------+-----------+--------------+\n | -13 | -190 | -48 | -61 |\n +-----------+---------------------+-----------+--------------+\n | -10 | -319 | -80 | -90 |\n +-----------+---------------------+-----------+--------------+\n | -6 | -248 | -62 | -68 |\n +-----------+---------------------+-----------+--------------+\n | 2 | -58 | -15 | -13 |\n +-----------+---------------------+-----------+--------------+\n | 8 | 137 | 34 | 42 |\n +-----------+---------------------+-----------+--------------+\n | 8 | 236 | 59 | 67 |\n +-----------+---------------------+-----------+--------------+\n | 6 | 191 | 47 | 53 |\n +-----------+---------------------+-----------+--------------+\n | 0 | 53 | 13 | 13 |\n +-----------+---------------------+-----------+--------------+\n | -3 | -93 | -24 | -27 |\n +-----------+---------------------+-----------+--------------+\n | -5 | -161 | -41 | -46 |\n +-----------+---------------------+-----------+--------------+\n | -4 | -134 | -34 | -38 |\n +-----------+---------------------+-----------+--------------+\n | -1 | -44 | -11 | -12 |\n +-----------+---------------------+-----------+--------------+\n | 1 | 52 | 13 | 14 |\n +-----------+---------------------+-----------+--------------+\n | 1 | 94 | 23 | 24 |\n +-----------+---------------------+-----------+--------------+\n | 4 | 60 | 15 | 19 |\n +-----------+---------------------+-----------+--------------+\n | 2 | 17 | 4 | 6 |\n +-----------+---------------------+-----------+--------------+\n | 2 | -24 | -6 | -4 |\n +-----------+---------------------+-----------+--------------+\n | 2 | -26 | -7 | -5 |\n +-----------+---------------------+-----------+--------------+\n | 0 | 1 | 0 | 0 |\n +-----------+---------------------+-----------+--------------+\n\n Table 49", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "By lining up all these samples, we get the following input for the MD5 checksum calculation process:", + "ja": "これらすべてのサンプルを並べることにより、MD5チェックサム計算プロセスの次の入力が得られます。" + }, + { + "indent": 3, + "text": "0x004F 6F4E 08C3 A6BC F32A 4335 0DE5 D2DA F40E 1813 06FC FB00", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "This indeed results in the MD5 checksum found in the streaminfo metadata block.", + "ja": "実際、これにより、StreaminfoメタデータブロックにあるMD5チェックサムが発生します。" + }, + { + "indent": 0, + "text": "Acknowledgments", + "section_title": true, + "ja": "謝辞" + }, + { + "indent": 3, + "text": "FLAC owes much to the many people who have advanced the audio compression field so freely. For instance:", + "ja": "FLACは、オーディオ圧縮フィールドを自由に進めた多くの人々に大いに負っています。例えば：" + }, + { + "indent": 6, + "text": "* Tony Robinson: He worked on Shorten, and his paper (see [Robinson-TR156]) is a good starting point on some of the basic methods used by FLAC. FLAC trivially extends and improves the fixed predictors, LPC coefficient quantization, and Rice coding used in Shorten.", + "ja": "* トニー・ロビンソン：彼はショーテンに取り組み、彼の論文（[ロビンソン-TR156を参照]を参照）は、FLACが使用する基本的な方法のいくつかの良い出発点です。FLACは、固定された予測因子、LPC係数量子化、および短縮で使用されるイネコーディングを簡単に拡張および改善します。" + }, + { + "indent": 6, + "text": "* Solomon W. Golomb and Robert F. Rice: Their universal codes are used by FLAC's entropy coder. See [Rice].", + "ja": "* Solomon W. GolombとRobert F. Rice：それらのユニバーサルコードは、FLACのエントロピーコーダーによって使用されています。[米]を参照してください。" + }, + { + "indent": 6, + "text": "* Norman Levinson and James Durbin: The FLAC reference encoder uses an algorithm developed and refined by them for determining the LPC coefficients from the autocorrelation coefficients. See [Durbin]).", + "ja": "* Norman LevinsonとJames Durbin：FLACリファレンスエンコーダーは、自己相関係数からLPC係数を決定するために開発および改良されたアルゴリズムを使用します。[Durbin]を参照してください。" + }, + { + "indent": 6, + "text": "* Claude Shannon: See [Shannon].", + "ja": "* クロード・シャノン：[シャノン]を参照。" + }, + { + "indent": 3, + "text": "The FLAC format, the FLAC reference implementation [FLAC-implementation], and the initial draft version of this document were originally developed by Josh Coalson. While many others have contributed since, this original effort is deeply appreciated.", + "ja": "FLAC形式、FLAC参照実装[FLAC-Implementation]、およびこのドキュメントの最初のドラフトバージョンは、もともとJosh Coalsonによって開発されました。それ以来、他の多くの人が貢献していますが、この当初の努力は深く感謝されています。" + }, + { + "indent": 0, + "text": "Authors' Addresses", + "section_title": true, + "ja": "著者のアドレス" + }, + { + "indent": 3, + "text": "Martijn van Beurden\nNetherlands\nEmail: mvanb1@gmail.com", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Andrew Weaver\nEmail: theandrewjw@gmail.com", + "raw": true, + "ja": "" + } + ] +} \ No newline at end of file diff --git a/data/9000/rfc9674-trans.json b/data/9000/rfc9674-trans.json new file mode 100644 index 000000000..e9c50820b --- /dev/null +++ b/data/9000/rfc9674-trans.json @@ -0,0 +1,300 @@ +{ + "title": { + "text": "RFC 9674 - Same-Origin Policy for the RPKI Repository Delta Protocol (RRDP)", + "ja": "RFC 9674 - RPKIリポジトリデルタプロトコル（RRDP）の同性ポリシー" + }, + "number": 9674, + "created_at": "2024-12-07 23:24:05.671198+09:00", + "updated_by": "", + "contents": [ + { + "indent": 0, + "text": "Internet Engineering Task Force (IETF) J. Snijders\nRequest for Comments: 9674 Fastly\nUpdates: 8182 December 2024\nCategory: Standards Track \nISSN: 2070-1721", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "Same-Origin Policy for the RPKI Repository Delta Protocol (RRDP)", + "section_title": true, + "ja": "RPKIリポジトリデルタプロトコル（RRDP）の同性ポリシー" + }, + { + "indent": 0, + "text": "Abstract", + "section_title": true, + "ja": "概要" + }, + { + "indent": 3, + "text": "This document describes a Same-Origin Policy (SOP) requirement for Resource Public Key Infrastructure (RPKI) Repository Delta Protocol (RRDP) servers and clients. Application of a SOP in RRDP client/ server communication isolates resources such as Delta and Snapshot files from different Repository Servers, reducing possible attack vectors. This document updates RFC 8182.", + "ja": "このドキュメントでは、リソース公開キーインフラストラクチャ（RPKI）リポジトリデルタプロトコル（RRDP）サーバーおよびクライアントの同性ポリシー（SOP）要件について説明します。RRDPクライアント/サーバー通信でのSOPのアプリケーションは、異なるリポジトリサーバーのデルタやスナップショットファイルなどのリソースを分離し、攻撃ベクトルの可能性を減らします。このドキュメントは、RFC 8182を更新します。" + }, + { + "indent": 0, + "text": "Status of This Memo", + "section_title": true, + "ja": "本文書の位置付け" + }, + { + "indent": 3, + "text": "This is an Internet Standards Track document.", + "ja": "これは、インターネット標準トラックドキュメントです。" + }, + { + "indent": 3, + "text": "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.", + "ja": "このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。" + }, + { + "indent": 3, + "text": "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/rfc9674.", + "ja": "このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9674で取得できます。" + }, + { + "indent": 0, + "text": "Copyright Notice", + "section_title": true, + "ja": "著作権表示" + }, + { + "indent": 3, + "text": "Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.", + "ja": "著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。" + }, + { + "indent": 3, + "text": "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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.", + "ja": "このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。" + }, + { + "indent": 0, + "text": "Table of Contents", + "section_title": true, + "ja": "目次" + }, + { + "indent": 3, + "text": "1. Introduction\n 1.1. Requirements Language\n2. Implications of Cross-Origin Resource Requests in RRDP\n3. Changes to RFC 8182\n 3.1. New Requirements for RRDP Repository Servers\n 3.2. New Requirements for Relying Parties Using RRDP\n4. Deployability in the Internet's Current RPKI\n5. Security Considerations\n6. IANA Considerations\n7. References\n 7.1. Normative References\n 7.2. Informative References\nAcknowledgements\nAuthor's Address", + "raw": true, + "toc": true, + "ja": "" + }, + { + "indent": 0, + "text": "1. Introduction", + "section_title": true, + "ja": "1. はじめに" + }, + { + "indent": 3, + "text": "This document specifies a Same-Origin Policy (SOP) requirement for RPKI Repository Delta Protocol (RRDP) servers and clients. The SOP concept is a security mechanism to restrict how a document loaded from one origin can cause interaction with resources from another origin. See [RFC6454] for an overview of the concept of an \"origin\". Application of a SOP in RRDP client/server communication isolates resources such as Delta and Snapshot files from different Repository Servers, reducing possible attack vectors. Another way to avoid undesirable implications (as described in Section 2) would be for a future version of RRDP to use relative URIs instead of absolute URIs. This document updates [RFC8182].", + "ja": "このドキュメントは、RPKIリポジトリデルタプロトコル（RRDP）サーバーおよびクライアントの同性ポリシー（SOP）要件を指定します。SOPの概念は、ある原点からロードされたドキュメントが別の起源からのリソースとの相互作用を引き起こす方法を制限するセキュリティメカニズムです。「起源」の概念の概要については、[RFC6454]を参照してください。RRDPクライアント/サーバー通信でのSOPのアプリケーションは、異なるリポジトリサーバーのデルタやスナップショットファイルなどのリソースを分離し、攻撃ベクトルの可能性を減らします。（セクション2で説明されているように）望ましくない意味を避ける別の方法は、RRDPの将来のバージョンが絶対的なURIの代わりに相対URIを使用することです。このドキュメントは[RFC8182]を更新します。" + }, + { + "indent": 0, + "text": "1.1. Requirements Language", + "section_title": true, + "ja": "1.1. 要件言語" + }, + { + "indent": 3, + "text": "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.", + "ja": "キーワード「必須」、「必要」、「必須」、「shall」、「shall」、「shill \"of\"、 \"nove\"、 \"becommended\"、 \"becommented\"、 \"may\"、 \"optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。" + }, + { + "indent": 0, + "text": "2. Implications of Cross-Origin Resource Requests in RRDP", + "section_title": true, + "ja": "2. RRDPでのクロスオリジンリソース要求の意味" + }, + { + "indent": 3, + "text": "The first RRDP specification did not explicitly disallow 'cross-origin' URI references from the Update Notification file (Section 3.5.1 of [RFC8182]) towards Delta (Section 3.5.3 of [RFC8182]) and Snapshot (Section 3.5.2 of [RFC8182]) files, and it was silent on the topic of HTTP Redirection (Section 15.4 of [RFC9110]).", + "ja": "最初のRRDP仕様は、デルタ（[RFC8182]のセクション3.5.3）およびスナップショット（セクション3.5.2のセクション3.5.3）に向けて、更新通知ファイル（[RFC8182]のセクション3.5.1）から「クロスオリジン」URI参照を明示的に禁止していませんでした。[RFC8182]）ファイル、およびHTTPリダイレクトのトピック（[RFC9110]のセクション15.4）については沈黙していました。" + }, + { + "indent": 3, + "text": "The implication of cross-origin references in Update Notification files is that one Repository Server can reference RRDP resources on another Repository Server and in doing so inappropriately increase the resource consumption for both RRDP clients and the referenced Repository Server. An adversary could also employ cross-origin HTTP Redirects towards other Repository Servers, causing similar undesirable behavior.", + "ja": "更新通知ファイルにおけるクロスオリジン参照の意味は、1つのリポジトリサーバーが別のリポジトリサーバーでRRDPリソースを参照し、RRDPクライアントと参照されるリポジトリサーバーの両方のリソース消費を不適切に増やすことができることです。敵は、他のリポジトリサーバーに向けて、オリジンクロスHTTPリダイレクトを採用し、同様の望ましくない動作を引き起こす可能性があります。" + }, + { + "indent": 0, + "text": "3. Changes to RFC 8182", + "section_title": true, + "ja": "3. RFC 8182の変更" + }, + { + "indent": 3, + "text": "To overcome the issue described in Section 2, RRDP Repository Servers and Clients MUST apply a Same-Origin Policy to both the URIs referenced in an Update Notification File and any HTTP Redirects.", + "ja": "セクション2で説明されている問題を克服するには、RRDPリポジトリサーバーとクライアントは、更新通知ファイルで参照されているURIとHTTPリダイレクトの両方に同様のオリジンポリシーを適用する必要があります。" + }, + { + "indent": 0, + "text": "3.1. New Requirements for RRDP Repository Servers", + "section_title": true, + "ja": "3.1. RRDPリポジトリサーバーの新しい要件" + }, + { + "indent": 3, + "text": "The following checklist items are added to Section 3.5.1.3 of [RFC8182]:", + "ja": "次のチェックリスト項目は、[RFC8182]のセクション3.5.1.3に追加されます。" + }, + { + "indent": 3, + "text": "NEW", + "ja": "新しい" + }, + { + "indent": 6, + "text": "* The \"uri\" attribute in the snapshot element and optional delta elements MUST be part of the same origin (i.e., represent the same principal), meaning referenced URIs MUST have the same scheme, host, and port as the URI for the Update Notification File specified in the referring RRDP SIA AccessDescription.", + "ja": "* スナップショット要素とオプションのデルタ要素の「URI」属性は、同じ原点の一部でなければなりません（つまり、同じプリンシパルを表します）。参照RRDP SIA AccessDescriptionで指定されています。" + }, + { + "indent": 6, + "text": "* The Repository Server MUST NOT respond with HTTP Redirects towards locations with an origin different from the origin of the Update Notification File specified in the referring RRDP SIA AccessDescription.", + "ja": "* リポジトリサーバーは、参照RRDP SIA AccessDescriptionで指定された更新通知ファイルの起源とは異なる原点を持つ場所にHTTPリダイレクトを使用して応答してはなりません。" + }, + { + "indent": 0, + "text": "3.2. New Requirements for Relying Parties Using RRDP", + "section_title": true, + "ja": "3.2. RRDPを使用して当事者に依存するための新しい要件" + }, + { + "indent": 3, + "text": "The following adds to Section 3.4.1 of [RFC8182]:", + "ja": "以下は、[RFC8182]のセクション3.4.1に追加されます。" + }, + { + "indent": 3, + "text": "NEW", + "ja": "新しい" + }, + { + "indent": 6, + "text": "* The Relying Party MUST verify whether the \"uri\" attributes in the Update Notification File are of the same origin as the Update Notification File itself. If this verification fails, the file MUST be rejected and RRDP cannot be used; see Section 3.4.5 for considerations. Implementations SHOULD log a message when cross-origin referrals are detected.", + "ja": "* 頼る当事者は、更新通知ファイルの「URI」属性が更新通知ファイル自体と同じ起源であるかどうかを確認する必要があります。この検証が失敗した場合、ファイルを拒否する必要があり、RRDPを使用できません。考慮事項については、セクション3.4.5を参照してください。オリジンの紹介が検出されたときに、実装にメッセージを記録する必要があります。" + }, + { + "indent": 6, + "text": "* The Relying Party MUST NOT follow HTTP Redirection that results from attempts to download Update Notification, Delta, and Snapshot files if the target origin is different from the origin of the Update Notification File specified in the referring RRDP SIA AccessDescription. If this verification fails, the RRDP session MUST be rejected and RRDP cannot be used; see Section 3.4.5 for considerations. Implementations SHOULD log a message when cross-origin redirects are detected.", + "ja": "* 頼る当事者は、ターゲットの原点が参照RRDP SIA AccessDescriptionで指定された更新通知ファイルの原点とは異なる場合、更新通知、Delta、およびSnapshotファイルをダウンロードしようとするHTTPリダイレクトに従ってはいけません。この検証が失敗した場合、RRDPセッションを拒否する必要があり、RRDPを使用できません。考慮事項については、セクション3.4.5を参照してください。クロスオリジンリダイレクトが検出された場合、実装はメッセージを記録する必要があります。" + }, + { + "indent": 0, + "text": "4. Deployability in the Internet's Current RPKI", + "section_title": true, + "ja": "4. インターネットの現在のRPKIでの展開性" + }, + { + "indent": 3, + "text": "Analyzing the [rpkiviews] archives for the period from April to September 2024, only one RRDP server (reached following the Trust Anchor Locators (TALs) of the five Regional Internet Registries) employed a same-origin HTTP redirect. In the period October 2021 - October 2024 no RRDP Repository Servers were observed that employed cross-origin URIs in Update Notification Files.", + "ja": "2024年4月から9月までの期間の[RPKiviews]アーカイブを分析すると、同様のHTTPリダイレクトを採用したRRDPサーバー（5つの地域インターネットレジストリのトラストアンカーロケーター（TALS）に続いて到達）のみが到達しました。2021年10月 - 2024年10月に、更新通知ファイルでクロスオリジンURIを使用したRRDPリポジトリサーバーは観察されませんでした。" + }, + { + "indent": 3, + "text": "This means that imposing a requirement for the application of a Same-Origin Policy does not cause any existing commonly used RRDP Repository Server operations to become non-compliant.", + "ja": "これは、同じオーリジンポリシーを適用するための要件を課しても、既存の一般的に使用されるRRDPリポジトリサーバー操作が非準拠にならないことを意味します。" + }, + { + "indent": 0, + "text": "5. Security Considerations", + "section_title": true, + "ja": "5. セキュリティに関する考慮事項" + }, + { + "indent": 3, + "text": "This document addresses an oversight in the original RRDP specification: Cross-origin requests are detrimental as they allow one repository operator to increase resource consumption for other repository operators and RRDP clients.", + "ja": "このドキュメントは、元のRRDP仕様の監視に対処します。1つのリポジトリオペレーターが他のリポジトリオペレーターおよびRRDPクライアントのリソース消費を増やすことができるため、クロスオリジン要求は有害です。" + }, + { + "indent": 0, + "text": "6. IANA Considerations", + "section_title": true, + "ja": "6. IANAの考慮事項" + }, + { + "indent": 3, + "text": "This document has no IANA actions.", + "ja": "このドキュメントにはIANAアクションがありません。" + }, + { + "indent": 0, + "text": "7. References", + "section_title": true, + "ja": "7. 参考文献" + }, + { + "indent": 0, + "text": "7.1. Normative References", + "section_title": true, + "ja": "7.1. 引用文献" + }, + { + "indent": 3, + "text": "[RFC2119] Bradner, S., \"Key words for use in RFCs to Indicate\n Requirement Levels\", BCP 14, RFC 2119,\n DOI 10.17487/RFC2119, March 1997,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC6454] Barth, A., \"The Web Origin Concept\", RFC 6454,\n DOI 10.17487/RFC6454, December 2011,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8174] Leiba, B., \"Ambiguity of Uppercase vs Lowercase in RFC\n 2119 Key Words\", BCP 14, RFC 8174, DOI 10.17487/RFC8174,\n May 2017, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein,\n \"The RPKI Repository Delta Protocol (RRDP)\", RFC 8182,\n DOI 10.17487/RFC8182, July 2017,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,\n Ed., \"HTTP Semantics\", STD 97, RFC 9110,\n DOI 10.17487/RFC9110, June 2022,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "7.2. Informative References", + "section_title": true, + "ja": "7.2. 参考引用" + }, + { + "indent": 3, + "text": "[rpkiviews]\n Snijders, J., \"rpkiviews\", .", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "Acknowledgements", + "section_title": true, + "ja": "謝辞" + }, + { + "indent": 3, + "text": "The author wishes to thank Theo Buehler, Claudio Jeker, Alberto Leiva, Tim Bruijnzeels, Ties de Kock, Martin Hoffmann, and Mikhail Puzanov for their helpful feedback, comments, and implementation work. The author wishes to thank Keyur Patel, Meral Shirazipour, Niclas Comstedt, Dan Harkins, Erik Kline, Roman Danyliw, and Éric Vyncke for their review.", + "ja": "著者は、Theo Buehler、Claudio Jeker、Alberto Leiva、Tim Bruijnzeels、Ties de Kock、Martin Hoffmann、およびMikhail Puzanovに有益なフィードバック、コメント、実装作業に感謝したいと考えています。著者は、Keyur Patel、Meral Shirazipour、Niclas Comstedt、Dan Harkins、Erik Kline、Roman Danyliw、Eric Vynckeにレビューに感謝したいと考えています。" + }, + { + "indent": 0, + "text": "Author's Address", + "section_title": true, + "ja": "著者の連絡先" + }, + { + "indent": 3, + "text": "Job Snijders\nFastly\nAmsterdam\nNetherlands\nEmail: job@fastly.com", + "raw": true, + "ja": "" + } + ] +} \ No newline at end of file diff --git a/data/9000/rfc9683-trans.json b/data/9000/rfc9683-trans.json new file mode 100644 index 000000000..7a510504f --- /dev/null +++ b/data/9000/rfc9683-trans.json @@ -0,0 +1,1934 @@ +{ + "title": { + "text": "RFC 9683 - Remote Integrity Verification of Network Devices Containing Trusted Platform Modules", + "ja": "RFC 9683 - 信頼できるプラットフォームモジュールを含むネットワークデバイスのリモート整合性検証" + }, + "number": 9683, + "created_at": "2024-12-08 23:24:06.124496+09:00", + "updated_by": "", + "contents": [ + { + "indent": 0, + "text": "Internet Engineering Task Force (IETF) G. C. Fedorkow, Ed.\nRequest for Comments: 9683 Juniper Networks, Inc.\nCategory: Informational E. Voit\nISSN: 2070-1721 Cisco\n J. Fitzgerald-McKay\n National Security Agency\n December 2024", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "Remote Integrity Verification of Network Devices Containing Trusted Platform Modules", + "section_title": true, + "ja": "信頼できるプラットフォームモジュールを含むネットワークデバイスのリモート整合性検証" + }, + { + "indent": 0, + "text": "Abstract", + "section_title": true, + "ja": "概要" + }, + { + "indent": 3, + "text": "This document describes a workflow for remote attestation of the integrity of firmware and software installed on network devices that contain Trusted Platform Modules (TPMs), as defined by the Trusted Computing Group (TCG), or equivalent hardware implementations that include the protected capabilities, as provided by TPMs.", + "ja": "このドキュメントでは、信頼できるコンピューティンググループ（TCG）によって定義されている信頼できるプラットフォームモジュール（TPM）を含むネットワークデバイスにインストールされているファームウェアとソフトウェアの整合性をリモート認証するためのワークフローについて説明します。TPMSによって提供されます。" + }, + { + "indent": 0, + "text": "Status of This Memo", + "section_title": true, + "ja": "本文書の位置付け" + }, + { + "indent": 3, + "text": "This document is not an Internet Standards Track specification; it is published for informational purposes.", + "ja": "このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。" + }, + { + "indent": 3, + "text": "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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.", + "ja": "このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、インターネット標準のあらゆるレベルの候補者であるわけではありません。RFC 7841のセクション2を参照してください。" + }, + { + "indent": 3, + "text": "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/rfc9683.", + "ja": "このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9683で取得できます。" + }, + { + "indent": 0, + "text": "Copyright Notice", + "section_title": true, + "ja": "著作権表示" + }, + { + "indent": 3, + "text": "Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.", + "ja": "著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。" + }, + { + "indent": 3, + "text": "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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.", + "ja": "このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。" + }, + { + "indent": 0, + "text": "Table of Contents", + "section_title": true, + "ja": "目次" + }, + { + "indent": 3, + "text": "1. Introduction\n 1.1. Requirements Notation\n 1.2. Terminology\n 1.3. Document Organization\n 1.4. Goals\n 1.5. Description of Remote Integrity Verification (RIV)\n 1.6. Solution Requirements\n 1.7. Scope\n 1.7.1. Out of Scope\n2. Solution Overview\n 2.1. RIV Software Configuration Attestation Using TPM\n 2.1.1. What Does RIV Attest?\n 2.1.2. Notes on PCR Allocations\n 2.2. RIV Keying\n 2.3. RIV Information Flow\n 2.4. RIV Simplifying Assumptions\n 2.4.1. Reference Integrity Manifests (RIMs)\n 2.4.2. Attestation Logs\n3. Standards Components\n 3.1. Prerequisites for RIV\n 3.1.1. Unique Device Identity\n 3.1.2. Keys\n 3.1.3. Appraisal Policy for Evidence\n 3.2. Reference Model for Challenge-Response\n 3.2.1. Transport and Encoding\n 3.3. Centralized vs. Peer-to-Peer\n4. Privacy Considerations\n5. Security Considerations\n 5.1. Keys Used in RIV\n 5.2. Prevention of Spoofing and Person-in-the-Middle Attacks\n 5.3. Replay Attacks\n 5.4. Owner-Signed Keys\n 5.5. Other Factors for Trustworthy Operation\n6. IANA Considerations\n7. Conclusion\n8. References\n 8.1. Normative References\n 8.2. Informative References\nAppendix A. Supporting Materials\n A.1. Using a TPM for Attestation\n A.2. Root of Trust for Measurement (RTM)\n A.3. Layering Model for Network Equipment Attester and Verifier\n A.4. Implementation Notes\nAcknowledgements\nAuthors' Addresses", + "raw": true, + "toc": true, + "ja": "" + }, + { + "indent": 0, + "text": "1. Introduction", + "section_title": true, + "ja": "1. はじめに" + }, + { + "indent": 3, + "text": "There are many aspects to consider in fielding a trusted computing device, from operating systems to applications. Mechanisms to prove that a device installed at a customer's site is authentic (i.e., not counterfeit) and has been configured with authorized software, all as part of a trusted supply chain, are just a few of the many aspects that need to be considered concurrently to have confidence that a device is truly trustworthy.", + "ja": "オペレーティングシステムからアプリケーションまで、信頼できるコンピューティングデバイスをフィールドする際に考慮すべき多くの側面があります。顧客のサイトにインストールされているデバイスが本物であり（つまり、偽造ではない）、信頼できるサプライチェーンの一部として認定ソフトウェアで構成されていることを証明するメカニズムは、同時に考慮する必要がある多くの側面のほんの一部ですデバイスが本当に信頼できると確信すること。" + }, + { + "indent": 3, + "text": "A generic architecture for remote attestation has been defined in [RFC9334]. Additionally, use cases for remotely attesting networking devices are discussed within Section 5 of [RATS-USECASES]. However, these documents do not provide sufficient guidance for network equipment vendors and operators to design, build, and deploy interoperable devices.", + "ja": "リモートの認証のための一般的なアーキテクチャは、[RFC9334]で定義されています。さらに、ネットワークデバイスをリモートで証明するためのユースケースについては、[rats-secases]のセクション5で説明します。ただし、これらのドキュメントでは、ネットワーク機器ベンダーとオペレーターが相互運用可能なデバイスを設計、構築、展開するのに十分なガイダンスを提供していません。" + }, + { + "indent": 3, + "text": "The intent of this document is to provide such guidance. It does this by outlining the Remote Integrity Verification (RIV) problem and then by identifying the necessary elements to get the complete, scalable attestation procedure working with commercial networking products such as routers, switches, and firewalls. An underlying assumption is the availability within the device of a cryptoprocessor that is compatible with the Trusted Platform Module specifications [TPM-1.2] [TPM-2.0] to enable the trustworthy, remote assessment of the device's software and hardware.", + "ja": "このドキュメントの意図は、そのようなガイダンスを提供することです。これは、リモートの整合性検証（RIV）の問題を概説し、必要な要素を識別して、ルーター、スイッチ、ファイアウォールなどの商用ネットワーキング製品と連携する完全でスケーラブルな証明手順を取得することにより行います。根本的な仮定は、信頼できるプラットフォームモジュール仕様[TPM-1.2] [TPM-2.0]と互換性のある暗号プロセッサのデバイス内の可用性であり、デバイスのソフトウェアとハードウェアの信頼できるリモート評価を可能にします。" + }, + { + "indent": 0, + "text": "1.1. Requirements Notation", + "section_title": true, + "ja": "1.1. 要件表記" + }, + { + "indent": 3, + "text": "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.", + "ja": "「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 \"not\"、 \"becommended\"、 \"becommented\"、 \"may\"、 \"optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。" + }, + { + "indent": 0, + "text": "1.2. Terminology", + "section_title": true, + "ja": "1.2. 用語" + }, + { + "indent": 3, + "text": "A number of terms are reused from [RFC9334]. These include Appraisal Policy for Evidence, Attestation Result, Attester, Evidence, Reference Value, Relying Party, Verifier, and Verifier Owner.", + "ja": "[RFC9334]から多くの用語が再利用されます。これらには、証拠、証明の結果、attester、証拠、参照値、依存者、検証者、および検証者の所有者に関する評価ポリシーが含まれます。" + }, + { + "indent": 3, + "text": "Additionally, this document defines the following term:", + "ja": "さらに、このドキュメントは次の用語を定義します。" + }, + { + "indent": 3, + "text": "Attestation:", + "ja": "証明：" + }, + { + "indent": 12, + "text": "The process of generating, conveying, and appraising claims, backed by evidence, about device trustworthiness characteristics, including supply chain trust, identity, device provenance, software configuration, device composition, compliance to test suites, functional and assurance evaluations, etc.", + "ja": "サプライチェーンの信頼、アイデンティティ、デバイスの起源、ソフトウェア構成、デバイスの構成、テストスイート、機能および保証評価など、デバイスの信頼性の特性について、証拠に裏付けられた主張を生成、伝達、および評価するプロセス。" + }, + { + "indent": 3, + "text": "The goal of attestation is simply to assure an administrator or auditor that the device's configuration and software were authentic and unmodified when the device started. The determination of software authenticity is not prescribed in this document, but it's typically taken to mean a software image generated by an authority trusted by the administrator, such as the device manufacturer.", + "ja": "証明の目標は、デバイスの構成とソフトウェアがデバイスの開始時に本物であり、変更されていないことを管理者または監査人に保証することです。ソフトウェアの信頼性の決定はこのドキュメントでは規定されていませんが、通常、デバイスメーカーなどの管理者が信頼している当局によって生成されるソフトウェアイメージを意味すると考えられています。" + }, + { + "indent": 3, + "text": "Within the context of the Trusted Computing Group (TCG), the scope of attestation is typically narrowed to describe the process by which an independent Verifier can obtain cryptographic proof as to the identity of the device in question, evidence of the integrity of the device's software that was loaded upon startup, and verification that the current configuration matches the intended configuration. For network equipment, a Verifier capability can be embedded in a Network Management Station, a posture collection server, or other network analytics tool (such as a software asset management solution, or a threat detection and mitigation tool, etc.). This document focuses on a specific subset of attestation tasks, defined here as Remote Integrity Verification (RIV), and informally referred to as attestation. RIV in this document takes a network-equipment-centric perspective that includes a set of protocols and procedures for determining whether a particular device was launched with authentic software, starting from Roots of Trust. While there are many ways to accomplish attestation, RIV sets out a specific set of protocols and tools that work in environments commonly found in network equipment. RIV does not cover other device characteristics that could be attested (e.g., geographic location or connectivity; see [RATS-USECASES]), although it does provide evidence of a secure infrastructure to increase the level of trust in other device characteristics attested by other means (e.g., by Entity Attestation Tokens [RATS-EAT]).", + "ja": "信頼できるコンピューティンググループ（TCG）のコンテキスト内で、実際には、独立した検証者が問題のデバイスのアイデンティティ、デバイスのソフトウェアの整合性の証拠に関して暗号化された証明を得ることができるプロセスを説明するために、認証の範囲が狭くなりますこれはスタートアップ時にロードされ、現在の構成が意図した構成と一致することを確認しました。ネットワーク機器の場合、ネットワーク管理ステーション、姿勢収集サーバー、またはその他のネットワーク分析ツール（ソフトウェア資産管理ソリューション、脅威検出および緩和ツールなど）に検証機能を埋め込むことができます。このドキュメントは、ここではリモート整合性検証（RIV）として定義され、非公式には証明と呼ばれる特定の証明タスクのサブセットに焦点を当てています。このドキュメントのRIVは、特定のデバイスが信頼のルーツから始まる本物のソフトウェアで起動されたかどうかを判断するための一連のプロトコルと手順を含むネットワークエクイプメント中心の視点を取得します。認証を達成するには多くの方法がありますが、RIVはネットワーク機器で一般的に見られる環境で機能する特定のプロトコルとツールのセットを設定します。RIVは、証明できる他のデバイスの特性をカバーしません（例：地理的位置や接続性; [rats-usecases]を参照）。（例えば、エンティティの証明トークン[rats-eat]）。" + }, + { + "indent": 3, + "text": "In line with definitions found in [RFC9334], this document uses the term Endorser to refer to the role that signs identity and attestation certificates used by the Attester, while Reference Values are signed by a Reference Value Provider. Typically, the manufacturer of a network device would be accepted as both the Endorser and Reference Value Provider, although the choice is ultimately up to the Verifier Owner.", + "ja": "[RFC9334]で見つかった定義に沿って、このドキュメントでは、エンダーザーという用語を使用して、参照値は参照値プロバイダーによって署名されている間、Attesterが使用する証明書に署名する役割と証明証明書を参照します。通常、ネットワークデバイスのメーカーは、最終的には検証者の所有者次第ですが、[エンサーと参照価値プロバイダーの両方として受け入れられます。" + }, + { + "indent": 0, + "text": "1.3. Document Organization", + "section_title": true, + "ja": "1.3. ドキュメント組織" + }, + { + "indent": 3, + "text": "The remainder of this document is organized into several sections:", + "ja": "このドキュメントの残りの部分は、いくつかのセクションに編成されています。" + }, + { + "indent": 6, + "text": "* The remainder of this section covers goals and requirements, plus a top-level description of RIV.", + "ja": "* このセクションの残りは、目標と要件に加えて、RIVのトップレベルの説明をカバーしています。" + }, + { + "indent": 6, + "text": "* The Solution Overview section (Section 2) outlines how RIV works.", + "ja": "* ソリューションの概要セクション（セクション2）では、RIVの仕組みの概要を説明します。" + }, + { + "indent": 6, + "text": "* The Standards Components section (Section 3) links components of RIV to normative standards.", + "ja": "* 標準コンポーネントセクション（セクション3）は、RIVのコンポーネントを規範的標準にリンクします。" + }, + { + "indent": 6, + "text": "* The Privacy and Security Considerations sections (Sections 4 and 5) shows how specific features of RIV contribute to the trustworthiness of the Attestation Result.", + "ja": "* プライバシーとセキュリティの考慮事項セクション（セクション4および5）は、RIVの特定の特徴が認証結果の信頼性にどのように貢献するかを示しています。" + }, + { + "indent": 6, + "text": "* Supporting material is in an appendix (Appendix A).", + "ja": "* サポート資料は付録（付録A）にあります。" + }, + { + "indent": 0, + "text": "1.4. Goals", + "section_title": true, + "ja": "1.4. 目標" + }, + { + "indent": 3, + "text": "Network operators benefit from a trustworthy attestation mechanism that provides assurance that their network comprises authentic equipment and has loaded software free of known vulnerabilities and unauthorized tampering. In line with the overall goal of assuring integrity, attestation can be used to assist in asset management, vulnerability and compliance assessment, plus configuration management.", + "ja": "ネットワークオペレーターは、ネットワークが本物の機器で構成され、既知の脆弱性や不正な改ざんのないソフトウェアをロードしたという保証を提供する信頼できる証明メカニズムの恩恵を受けます。完全性を保証するという全体的な目標に沿って、資産管理、脆弱性、コンプライアンス評価、および構成管理を支援するために証明を使用できます。" + }, + { + "indent": 3, + "text": "The RIV attestation workflow outlined in this document is intended to meet the following high-level goals:", + "ja": "このドキュメントで概説されているRIVの証明ワークフローは、次の高レベルの目標を満たすことを目的としています。" + }, + { + "indent": 6, + "text": "* Provable Device Identity - This specification requires that an Attester (i.e., the attesting device) includes a cryptographic identifier unique to each device. Effectively, this means that the device's TPM must be provisioned with this during the manufacturing cycle.", + "ja": "* 証明可能なデバイスのID-この仕様では、Attester（つまり、証明デバイス）には、各デバイスに固有の暗号化識別子が含まれることが必要です。事実上、これは、製造サイクル中にデバイスのTPMをこれでプロビジョニングする必要があることを意味します。" + }, + { + "indent": 6, + "text": "* Software Inventory - Key goals are to identify the software release(s) installed on the Attester and to provide evidence that the software stored within hasn't been altered without authorization.", + "ja": "* ソフトウェアインベントリ - 重要な目標は、Attesterにインストールされたソフトウェアリリースを特定し、内部に保存されているソフトウェアが許可なしに変更されていないという証拠を提供することです。" + }, + { + "indent": 6, + "text": "* Verifiability - Verification of the device's software and configuration shows that the software that the administrator authorized for use was actually launched.", + "ja": "* 検証可能性 - デバイスのソフトウェアと構成の検証は、管理者が使用することを許可したソフトウェアが実際に起動されたことを示しています。" + }, + { + "indent": 3, + "text": "In addition, RIV is designed to operate either in a centralized environment, such as with a central authority that manages and configures a number of network devices, or \"peer-to-peer\", where network devices independently verify one another to establish a trust relationship. (See Section 3.3.)", + "ja": "さらに、RIVは、多くのネットワークデバイスを管理および構成する中央当局など、集中環境で動作するように設計されています。関係。（セクション3.3を参照してください。）" + }, + { + "indent": 0, + "text": "1.5. Description of Remote Integrity Verification (RIV)", + "section_title": true, + "ja": "1.5. リモート整合性検証（RIV）の説明" + }, + { + "indent": 3, + "text": "Attestation requires two interlocking mechanisms between the Attester network device and the Verifier:", + "ja": "証明には、Attesterネットワークデバイスと検証器の間に2つの連動メカニズムが必要です。" + }, + { + "indent": 6, + "text": "* Device Identity is the mechanism that provides trusted identity, which can reassure network managers that the specific devices they ordered from authorized manufacturers for attachment to their network are those that were installed and that they continue to be present in their network. As part of the mechanism for Device Identity, cryptographic proof of the manufacturer's identity is also provided.", + "ja": "* デバイスのアイデンティティは、信頼できるアイデンティティを提供するメカニズムであり、ネットワークへの添付のために認可されたメーカーから注文した特定のデバイスがインストールされたものであり、ネットワークに存在し続けることをネットワークマネージャーに安心させることができます。デバイスアイデンティティのメカニズムの一部として、メーカーのアイデンティティの暗号化された証明も提供されます。" + }, + { + "indent": 6, + "text": "* Software Measurement is the mechanism that reports the state of mutable software components on the device and that can assure administrators that they have known, authentic software configured to run in their network.", + "ja": "* ソフトウェア測定は、デバイス上の可変ソフトウェアコンポーネントの状態を報告し、ネットワークで実行するように構成された本物のソフトウェアを知っている管理者に保証できるメカニズムです。" + }, + { + "indent": 3, + "text": "By using these two interlocking mechanisms, RIV, which is a component in a chain of procedures, can assure a network operator that the equipment in their network can be reliably identified and that authentic software of a known version is installed on each device. Equipment in the network includes devices that make up the network itself, such as routers, switches, and firewalls.", + "ja": "これら2つのインターロックメカニズムを使用することにより、一連の手順のコンポーネントであるRIVは、ネットワークオペレーターにネットワーク内の機器を確実に識別できること、および既知のバージョンの本物のソフトウェアが各デバイスにインストールされていることを保証できます。ネットワーク内の機器には、ルーター、スイッチ、ファイアウォールなど、ネットワーク自体を構成するデバイスが含まれています。" + }, + { + "indent": 3, + "text": "Software used to boot a device can be identified by a chain of measurements, anchored at the start by a Root of Trust for Measurement (RTM) (see Appendix A.2). An attestation function embedded in each stage, verified by the previous stage, measures the next stage and records the result in tamper-resistant storage. A measurement signifies the identity, integrity, and version of each software component registered with an Attester's TPM [TPM-1.2] [TPM-2.0] so that a subsequent verification stage can determine if the software installed is authentic, up-to-date, and free of tampering.", + "ja": "デバイスの起動に使用されるソフトウェアは、測定のための信頼のルート（RTM）によって開始時に固定された一連の測定によって識別できます（付録A.2を参照）。前の段階で検証された各段階に埋め込まれた証明関数は、次の段階を測定し、タンパー耐性ストレージの結果を記録します。測定は、AstesterのTPM [TPM-1.2] [TPM-2.0]に登録された各ソフトウェアコンポーネントのID、整合性、およびバージョンを意味します。改ざんされていません。" + }, + { + "indent": 3, + "text": "RIV includes several major processes, which are split between the Attester and Verifier:", + "ja": "RIVにはいくつかの主要なプロセスが含まれています。これらには、AttesterとVerifierの間に分割されています。" + }, + { + "indent": 8, + "text": "1. Generation of Evidence is the process whereby an Attester generates cryptographic proof (Evidence) of claims about device properties. In particular, the device identity and its software configuration are both of critical importance.", + "ja": "1. 証拠の生成とは、アテスターがデバイスプロパティに関する主張の暗号化された証明（証拠）を生成するプロセスです。特に、デバイスのIDとそのソフトウェア構成はどちらも非常に重要です。" + }, + { + "indent": 8, + "text": "2. Device Identification refers to the mechanism assuring the Relying Party (ultimately, a network administrator) of the identities of devices, and the identities of their manufacturers, that make up their network.", + "ja": "2. デバイスの識別とは、ネットワークを構成するデバイスのアイデンティティの依存者（最終的にはネットワーク管理者）とメーカーのアイデンティティを保証するメカニズムを指します。" + }, + { + "indent": 8, + "text": "3. Conveyance of Evidence reliably transports the collected Evidence from the Attester to a Verifier to allow a management station to perform a meaningful appraisal in Step 4. The transport is typically carried out via a management network. Although not required for reliable attestation, an encrypted channel may be used to provide integrity, authenticity, or confidentiality once attestation is complete. It should be noted that critical attestation evidence from the TPM is signed by a key known only to TPM, and is not dependent on encryption carried out as part of a reliable transport.", + "ja": "3. 証拠の伝達は、攻撃された証拠を、手順4で管理ステーションが有意義な評価を実行できるように、攻撃者から検証剤に確実に輸送されます。輸送は通常、管理ネットワークを介して実行されます。信頼できる証明には必要ありませんが、暗号化されたチャネルを使用して、完全性、信頼性、または機密性を提供することができます。TPMからの重要な証明の証拠は、TPMのみに知られているキーによって署名されており、信頼できる輸送の一部として実行される暗号化に依存していないことに注意する必要があります。" + }, + { + "indent": 8, + "text": "4. Finally, appraisal of evidence occurs. This is the process of verifying the Evidence received by a Verifier from the Attester and using an Appraisal Policy to develop an Attestation Result, which is used to inform decision-making. In practice, this means comparing the Attester's measurements reported as Evidence with the device configuration expected by the Verifier. Subsequently, the Appraisal Policy for Evidence might match Evidence found against Reference Values (aka Golden Measurements), which represent the intended configured state of the connected device.", + "ja": "4. 最後に、証拠の評価が発生します。これは、アテスターから検証者が受け取った証拠を検証し、評価ポリシーを使用して意思決定を通知するために使用される証明結果を作成するプロセスです。実際には、これは、検証剤によって予想されるデバイス構成との証拠として報告されているAttesterの測定値を比較することを意味します。その後、証拠の評価ポリシーは、接続されたデバイスの意図した構成状態を表す基準値（別名ゴールデン測定）に対して見つかった証拠と一致する可能性があります。" + }, + { + "indent": 3, + "text": "All implementations supporting this RIV specification require the support of the following three technologies:", + "ja": "このRIV仕様をサポートするすべての実装には、次の3つのテクノロジーのサポートが必要です。" + }, + { + "indent": 8, + "text": "1. Identity: Device identity in RIV is based on Device Identity (DevID) defined by IEEE Std 802.1AR [IEEE-802-1AR], coupled with careful supply-chain management by the manufacturer. The Initial DevID (IDevID) certificate contains a statement by the manufacturer that establishes the identity of the device as it left the factory. Some applications with a more complex post-manufacture supply chain (e.g., value added resellers), or with different privacy concerns, may want to use alternative mechanisms for platform authentication (for example, TCG Platform Certificates [PLATFORM-CERTS] or post-manufacture installation of Local DevID (LDevID)).", + "ja": "1. ID：RIVのデバイスIDは、IEEE STD 802.1AR [IEEE-802-1AR]によって定義されたデバイスID（Devid）に基づいており、メーカーによる慎重なサプライチェーン管理と組み合わされています。初期Devid（IDEVID）証明書には、工場を離れたときにデバイスの身元を確立するメーカーによるステートメントが含まれています。より複雑な製造後のサプライチェーン（バリューアドレスリセラーなど）、またはさまざまなプライバシーの懸念を伴う一部のアプリケーションは、プラットフォーム認証に代替メカニズムを使用することをお勧めします（たとえば、TCGプラットフォーム証明書[プラットフォーム洞窟]または製造後の製造後ローカルdevid（ldevid）のインストール）。" + }, + { + "indent": 8, + "text": "2. Platform attestation provides evidence of configuration of software elements present in the device. This form of attestation can be implemented with TPM Platform Configuration Registers (PCRs) and Quote and Log mechanisms, which provide cryptographically authenticated evidence to report what software was started on the device through the boot cycle. Successful attestation requires an unbroken chain from a boot-time Root of Trust through all layers of software needed to bring the device to an operational state, in which each stage computes the hash of components of the next stage, then updates the attestation log and the TPM. The TPM can then report the hashes of all the measured hashes as signed evidence called a Quote (see Appendix A.1 for an overview of TPM operation or [TPM-1.2] and [TPM-2.0] for many more details).", + "ja": "2. プラットフォームの証明は、デバイスに存在するソフトウェア要素の構成の証拠を提供します。この形式の証明は、TPMプラットフォーム構成レジスタ（PCR）と引用およびログメカニズムを使用して実装できます。このメカニズムは、ブートサイクルを通じてデバイスで開始されたソフトウェアを報告する暗号化された証拠を提供します。成功した証明には、デバイスを運用状態にするために必要なすべてのレイヤーのすべてのレイヤーを介して、信頼のブートタイムルートからの途切れないチェーンが必要です。各段階では、次の段階のコンポーネントのハッシュを計算し、証明ログとTPM。TPMは、引用と呼ばれる署名された証拠として測定されたすべてのハッシュのハッシュを報告できます（TPM操作の概要については、[TPM-1.2]および[TPM-2.0]の詳細については、付録A.1を参照）。" + }, + { + "indent": 8, + "text": "3. Signed Reference Values (aka reference integrity measurements) must be conveyed from the Reference Value Provider (the entity accepted as the software authority, often the manufacturer of the network device) to the Verifier.", + "ja": "3. 署名された参照値（別名参照整合性測定）は、参照値プロバイダー（ソフトウェア機関として受け入れられているエンティティ、しばしばネットワークデバイスの製造業者）から検証器に伝える必要があります。" + }, + { + "indent": 0, + "text": "1.6. Solution Requirements", + "section_title": true, + "ja": "1.6. 解決策要件" + }, + { + "indent": 3, + "text": "RIV must address the \"Lying Endpoint\" problem, in which malicious software on an endpoint may subvert the intended function and also prevent the endpoint from reporting its compromised status. (See Section 5 for further Security Considerations.)", + "ja": "RIVは、エンドポイント上の悪意のあるソフトウェアが意図した関数を破壊し、エンドポイントが侵害されたステータスを報告するのを防ぐ可能性がある「横になっているエンドポイント」の問題に対処する必要があります。（さらなるセキュリティに関する考慮事項については、セクション5を参照してください。）" + }, + { + "indent": 3, + "text": "RIV attestation is designed to be simple to deploy at scale. RIV should work \"out of the box\" as far as possible, that is, with the fewest possible provisioning steps or configuration databases needed at the end user's site. Network equipment is often required to \"self-configure\", to reliably reach out without manual intervention to prove its identity and operating posture, then download its own configuration, a process which precludes pre-installation configuration. See [RFC8572] for an example of Secure Zero Touch Provisioning (SZTP).", + "ja": "RIVの証明は、大規模な展開が簡単になるように設計されています。RIVは、可能な限り「箱から出して」作業する必要があります。つまり、エンドユーザーのサイトで必要な可能性のあるプロビジョニングステップまたは構成データベースが必要です。ネットワーク機器は、多くの場合、「自己構成」し、そのアイデンティティと動作姿勢を証明するために手動介入なしで確実に手を差し伸べ、その後、独自の構成をダウンロードするために必要です。安全なゼロタッチプロビジョニング（SZTP）の例については、[RFC8572]を参照してください。" + }, + { + "indent": 0, + "text": "1.7. Scope", + "section_title": true, + "ja": "1.7. 範囲" + }, + { + "indent": 3, + "text": "The need for assurance of software integrity, addressed by Remote Attestation, is a very general problem that could apply to most network-connected computing devices. However, this document includes several assumptions that limit the scope to network equipment (e.g., routers, switches, and firewalls):", + "ja": "リモートの証明によって対処されるソフトウェアの整合性を保証する必要性は、ほとんどのネットワーク接続コンピューティングデバイスに適用できる非常に一般的な問題です。ただし、このドキュメントには、ネットワーク機器（例：ルーター、スイッチ、ファイアウォールなど）に範囲を制限するいくつかの仮定が含まれています。" + }, + { + "indent": 6, + "text": "* This solution is for use in non-privacy-preserving applications (for example, networking or industrial Internet of Things (IoT) applications), which avoids the need for a Privacy Certification Authority (also called an Attestation CA) for Attestation Keys (AKs) [AIK-ENROLL] or TCG Platform Certificates [PLATFORM-CERTS].", + "ja": "* このソリューションは、非プリバシーを提供するアプリケーション（たとえば、ネットワーキングや産業用モノのインターネット（IoT）アプリケーション）で使用するためのものであり、証明キー（AK）のためのプライバシー認証局（ATSETATIATIAN CAとも呼ばれます）の必要性を回避します。[AIK-Enroll]またはTCGプラットフォーム証明書[プラットフォームキャット]。" + }, + { + "indent": 6, + "text": "* This document assumes network protocols that are common in network equipment such as YANG [RFC7950] and Network Configuration Protocol (NETCONF) [RFC6241], but not generally used in other applications.", + "ja": "* このドキュメントでは、Yang [RFC7950]やネットワーク構成プロトコル（NetConf）[RFC6241]などのネットワーク機器で一般的なネットワークプロトコルを想定していますが、他のアプリケーションでは一般的には使用されていません。" + }, + { + "indent": 6, + "text": "* The approach outlined in this document mandates the use of a TPM [TPM-1.2] [TPM-2.0] or a compatible cryptoprocessor.", + "ja": "* このドキュメントで概説されているアプローチでは、TPM [TPM-1.2] [TPM-2.0]または互換性のある暗号化プロセッサの使用が義務付けられています。" + }, + { + "indent": 0, + "text": "1.7.1. Out of Scope", + "section_title": true, + "ja": "1.7.1. 範囲外" + }, + { + "indent": 3, + "text": "Run-Time Attestation:", + "ja": "ランタイムの証明：" + }, + { + "indent": 12, + "text": "The Linux Integrity Measurement Architecture [IMA] attests each process launched after a device is started (and is in scope for RIV in general), but continuous run-time attestation of Linux or other multi-threaded operating system processes after the OS has started considerably expands the scope of the problem. Many researchers are working on that problem, but this document defers the problem of continuous, in-memory run-time attestation.", + "ja": "Linux Integrity測定アーキテクチャ[IMA]は、デバイスの開始後に起動した各プロセスを証明しています（および一般的にRIVの範囲にあります）が、OSがかなり開始した後、Linuxまたはその他のマルチスレッドオペレーティングシステムプロセスの継続的な実行時間証明問題の範囲を拡大します。多くの研究者がその問題に取り組んでいますが、この文書は、継続的でメモリのランタイムの証明の問題を扱います。" + }, + { + "indent": 3, + "text": "Multi-Vendor Embedded Systems:", + "ja": "マルチベンダー埋め込みシステム：" + }, + { + "indent": 12, + "text": "Additional coordination would be needed for devices that themselves comprise hardware and software from multiple vendors and are integrated by the end user. Although out of scope for this document, these issues are accommodated in [RFC9334].", + "ja": "複数のベンダーからのハードウェアとソフトウェアを構成し、エンドユーザーによって統合されているデバイスには、追加の調整が必要です。この文書の範囲外ですが、これらの問題は[RFC9334]に対応しています。" + }, + { + "indent": 3, + "text": "Processor Sleep Modes:", + "ja": "プロセッサスリープモード：" + }, + { + "indent": 12, + "text": "Network equipment typically does not \"sleep\", so sleep and hibernate modes are not considered. Although out of scope for RIV in this document, TCG specifications do encompass sleep and hibernate states, which could be incorporated into remote attestation for network equipment in the future, given a compelling need.", + "ja": "ネットワーク機器は通常「睡眠」ではないため、睡眠モードと冬眠モードは考慮されません。このドキュメントではRIVの範囲外ですが、TCG仕様には睡眠と冬眠状態が含まれます。これは、将来的には、将来のネットワーク機器のリモート証明書に組み込まれる可能性があります。" + }, + { + "indent": 3, + "text": "Virtualization and Containerization:", + "ja": "仮想化とコンテナ化：" + }, + { + "indent": 12, + "text": "In a non-virtualized system, the host OS is responsible for measuring each user-space file or process throughout the operational lifetime of the system. For virtualized systems, the host OS must verify the hypervisor, but then the hypervisor must manage its own chain of trust through the virtual machine. Virtualization and containerization technologies are increasingly used in network equipment, but are not considered in this document.", + "ja": "非仮想化システムでは、ホストOSは、システムの運用寿命を通じて各ユーザースペースファイルまたはプロセスを測定する責任があります。仮想化システムの場合、ホストOSはハイパーバイザーを検証する必要がありますが、ハイパーバイザーは仮想マシンを介して独自の信頼チェーンを管理する必要があります。仮想化およびコンテナ化技術は、ネットワーク機器でますます使用されていますが、このドキュメントでは考慮されていません。" + }, + { + "indent": 0, + "text": "2. Solution Overview", + "section_title": true, + "ja": "2. 解決策の概要" + }, + { + "indent": 0, + "text": "2.1. RIV Software Configuration Attestation Using TPM", + "section_title": true, + "ja": "2.1. TPMを使用したRIVソフトウェア構成の証明" + }, + { + "indent": 3, + "text": "RIV Attestation is a process that can be used to determine the identity of software running on a specifically identified device. The Remote Attestation steps of Section 1.5 are split into two phases as shown in Figure 1:", + "ja": "RIVの証明は、具体的に特定されたデバイスで実行されているソフトウェアのIDを決定するために使用できるプロセスです。図1に示すように、セクション1.5のリモート証明手順は2つのフェーズに分割されています。" + }, + { + "indent": 6, + "text": "* During system startup, or Boot Phase, each distinct software object is \"measured\" by the Attester. The object's identity, hash (i.e., cryptographic digest), and version information are recorded in a log. Hashes are also extended into the TPM (see Appendix A.1 for more on extending hashes) in a way that can be used to validate the log entries. The measurement process generally follows the layered chain-of-trust model used in Measured Boot, where each stage of the system measures the next one, and extends its measurement into the TPM, before launching it. See Section 3.2 of [RFC9334], \"Layered Attestation Environments\", for an architectural definition of this model.", + "ja": "* システムスタートアップ、またはブートフェーズ中、各個別のソフトウェアオブジェクトは、アテスターによって「測定」されます。オブジェクトのアイデンティティ、ハッシュ（つまり、暗号化ダイジェスト）、およびバージョン情報はログに記録されます。ハッシュは、ログエントリの検証に使用できる方法で、TPM（拡張ハッシュの詳細については付録A.1を参照）に拡張されます。測定プロセスは、一般に、測定されたブートで使用される層状のトラストチェーンモデルに従います。ここで、システムの各段階が次の段階を測定し、測定をTPMに拡張してから起動します。このモデルのアーキテクチャの定義については、[RFC9334]のセクション3.2 [階層化された証明環境]を参照してください。" + }, + { + "indent": 6, + "text": "* Once the device is running and has operational network connectivity, verification can take place. A separate Verifier, running in its own trusted environment, will interrogate the network device to retrieve the logs and a copy of the digests collected by hashing each software object, signed by an attestation private key secured by, but never released by, the TPM. The YANG model described in [RFC9684] facilitates this operation.", + "ja": "* デバイスが実行され、運用上のネットワーク接続があると、検証が行われます。独自の信頼できる環境で実行される別の検証者は、ネットワークデバイスを尋問して、各ソフトウェアオブジェクトをハッシュすることによって収集されたダイジェストのコピーを取得します。[RFC9684]に記載されているYangモデルは、この操作を促進します。" + }, + { + "indent": 3, + "text": "The result is that the Verifier can verify the device's identity by checking the subject [RFC5280] and signature of the certificate containing the TPM's attestation public key. The Verifier can then verify the log's correctness by accumulating all the hashes in the log and comparing that to the signed digests from the TPM. From there, the Verifier can validate the launched software by comparing the digests in the log with Reference Values.", + "ja": "その結果、検証者は、被験者[RFC5280]をチェックし、TPMの証明公開キーを含む証明書の署名をチェックすることにより、デバイスのIDを検証できます。次に、検証剤は、ログ内のすべてのハッシュを蓄積し、TPMからの署名されたダイジェストと比較することにより、ログの正確性を検証できます。そこから、検証者は、ログ内のダイジェストを参照値と比較することにより、起動されたソフトウェアを検証できます。" + }, + { + "indent": 3, + "text": "It should be noted that attestation and identity are inextricably linked; signed Evidence that a particular version of software was loaded is of little value without cryptographic proof of the identity of the Attester producing the Evidence.", + "ja": "証明とアイデンティティは密接にリンクされていることに注意する必要があります。特定のバージョンのソフトウェアがロードされたという署名された証拠は、証拠を作成しているアテスターのアイデンティティの暗号化された証拠なしではほとんど価値がありません。" + }, + { + "indent": 7, + "text": "+-------------------------------------------------------+\n| +---------+ +--------+ +--------+ +---------+ |\n| |UEFI BIOS|--->| Loader |-->| Kernel |--->|Userland | |\n| +---------+ +--------+ +--------+ +---------+ |\n| | | | |\n| | | | |\n| +------------+-----------+-+ |\n| Boot Phase | |\n| V |\n| +--------+ |\n| | TPM | |\n| +--------+ |\n| Router | |\n+--------------------------------|----------------------+\n |\n | Verification Phase\n | +-----------+\n +--->| Verifier |\n +-----------+\n\nReset---------------flow-of-time-during-boot...--------->", + "raw": true, + "ja": "" + }, + { + "indent": 18, + "text": "Figure 1: Layered RIV Attestation Model", + "ja": "図1：層状のRIV証明モデル" + }, + { + "indent": 3, + "text": "In the Boot Phase, measurements are \"extended\", or hashed, into the TPM as processes start, which result in the TPM containing hashes of all the measured hashes. Later, once the system is operational, signed digests are retrieved from the TPM during the Verification Phase for off-box analysis.", + "ja": "ブートフェーズでは、プロセスが開始されると、測定値がTPMに「拡張」またはハッシュされます。これにより、TPMにはすべての測定ハッシュのハッシュが含まれます。その後、システムが動作すると、署名されたダイジェストは、オフボックス分析のために検証フェーズ中にTPMから取得されます。" + }, + { + "indent": 0, + "text": "2.1.1. What Does RIV Attest?", + "section_title": true, + "ja": "2.1.1. RIVは何を証明していますか？" + }, + { + "indent": 3, + "text": "TPM attestation is focused on PCRs, but those registers are only vehicles for certifying accompanying Evidence conveyed in log entries. It is the hashes in log entries that are extended into PCRs, where the final PCR values can be retrieved in the form of a structure called a Quote, which is signed by an AK known only to the TPM. The use of multiple PCRs serves only to provide some independence between different classes of object so that one class of objects can be updated without changing the extended hash for other classes. Although PCRs can be used for any purpose, this section outlines the objects within the scope of this document that may be extended into the TPM.", + "ja": "TPMの証明はPCRSに焦点を当てていますが、これらのレジスタは、ログエントリで伝えられる添付の証拠を証明するための手段のみです。PCRSに拡張されたのは、ログエントリのハッシュであり、最終的なPCR値を引用と呼ばれる構造の形で取得できます。複数のPCRの使用は、異なるクラスのオブジェクト間である程度の独立性を提供するためだけに機能し、他のクラスの拡張ハッシュを変更せずに1つのクラスのオブジェクトを更新できます。PCRはあらゆる目的に使用できますが、このセクションでは、TPMに拡張される可能性のあるこのドキュメントの範囲内のオブジェクトの概要を説明します。" + }, + { + "indent": 3, + "text": "In general, assignment of measurements to PCRs is a policy choice made by the device manufacturer, selected to independently attest three classes of object:", + "ja": "一般に、PCRSへの測定の割り当ては、デバイスメーカーが作成したポリシーの選択であり、3つのクラスのオブジェクトを独立して証明するように選択されました。" + }, + { + "indent": 3, + "text": "Code:", + "ja": "コード：" + }, + { + "indent": 12, + "text": "Instructions to be executed by a CPU.", + "ja": "CPUによって実行される指示。" + }, + { + "indent": 3, + "text": "Configuration:", + "ja": "構成：" + }, + { + "indent": 12, + "text": "Many devices offer numerous options controlled by non-volatile configuration variables that can impact the device's security posture. These settings may have vendor defaults, but often can be changed by administrators, who may want to verify via attestation that the operational state of the settings match their intended state.", + "ja": "多くのデバイスは、デバイスのセキュリティ姿勢に影響を与える可能性のある不揮発性構成変数によって制御される多数のオプションを提供しています。これらの設定にはベンダーのデフォルトがある場合がありますが、多くの場合、設定の運用状態が意図した状態と一致することを証明して検証したい管理者によって変更される可能性があります。" + }, + { + "indent": 3, + "text": "Credentials:", + "ja": "資格：" + }, + { + "indent": 12, + "text": "Administrators may wish to verify via attestation that public keys and credentials outside the Root of Trust have not been subject to unauthorized tampering. (By definition, keys protecting the Root of Trust can't be verified independently.)", + "ja": "管理者は、信頼のルート外のパブリックキーと資格情報が不正な改ざんの影響を受けていないことを証明されていることを確認することをお勧めします。（定義上、信頼の根を保護するキーは独立して検証することはできません。）" + }, + { + "indent": 3, + "text": "The \"TCG PC Client Specific Platform Firmware Profile Specification\" [PC-CLIENT-BIOS-TPM-2.0] details what is to be measured during the Boot Phase of platform startup using a Unified Extensible Firmware Interface (UEFI) BIOS (), but the goal is simply to measure every bit of code executed in the process of starting the device, along with any configuration information related to security posture, leaving no gap for unmeasured code to remain undetected and potentially subverting the chain.", + "ja": "「TCG PCクライアント固有のプラットフォームファームウェアプロファイル仕様」[PC-Client-BIOS-TPM-2.0]は、統一された拡張可能なファームウェアインターフェイス（UEFI）BIOSを使用して、プラットフォームスタートアップのブートフェーズで測定するものを詳述します（）、しかし、目標は、デバイスを起動するプロセスで実行されたすべてのコードを、セキュリティ姿勢に関連する構成情報を測定することです。" + }, + { + "indent": 3, + "text": "For devices using a UEFI BIOS, [PC-CLIENT-BIOS-TPM-2.0] and [PC-CLIENT-EFI-TPM-1.2] give detailed normative requirements for PCR usage. For other platform architectures, where TCG normative requirements currently do not exist, Table 1 gives non-normative guidance for PCR assignment that generalizes the specific details of [PC-CLIENT-BIOS-TPM-2.0].", + "ja": "UEFI BIOSを使用したデバイスの場合、[PC-Client-BIOS-TPM-2.0]および[PC-Client-EFI-TPM-1.2]は、PCR使用に関する詳細な規範的要件を提供します。TCG規範要件が現在存在しない他のプラットフォームアーキテクチャの場合、表1は、[PC-Client-Bios-Bios-TPM-2.0]の特定の詳細を一般化するPCR割り当ての非規範的なガイダンスを示します。" + }, + { + "indent": 3, + "text": "By convention, most PCRs are assigned in pairs, with the even-numbered PCR used to measure executable code and the odd-numbered PCR used to measure whatever data and configuration are associated with that code. It is important to note that each PCR may contain results from dozens (or even thousands) of individual measurements.", + "ja": "慣習により、ほとんどのPCRはペアで割り当てられ、均等なPCRは実行可能性コードを測定するために使用され、そのコードに関連付けられているデータと構成を測定するために使用される奇数のPCRが使用されます。各PCRには、個々の測定値の数十（または数千）の結果が含まれている場合があることに注意することが重要です。" + }, + { + "indent": 3, + "text": "+===========================================+======================+\n| | Assigned PCR # |\n+===========================================+======+===============+\n| Function | Code | Configuration |\n+===========================================+======+===============+\n| Firmware Static Root of Trust (i.e., | 0 | 1 |\n| initial boot firmware and drivers) | | |\n+-------------------------------------------+------+---------------+\n| Drivers and initialization for optional | 2 | 3 |\n| or add-in devices | | |\n+-------------------------------------------+------+---------------+\n| OS loader code and configuration (i.e., | 4 | 5 |\n| the code launched by firmware) to load an | | |\n| operating system kernel. These PCRs | | |\n| record each boot attempt, and an | | |\n| identifier for where the loader was found | | |\n+-------------------------------------------+------+---------------+\n| Vendor-specific measurements during boot | 6 | 6 |\n+-------------------------------------------+------+---------------+\n| Secure Boot Policy. This PCR records | | 7 |\n| keys and configuration used to validate | | |\n| the OS loader | | |\n+-------------------------------------------+------+---------------+\n| Measurements made by the OS loader (e.g., | 8 | 9 |\n| GRUB2 for Linux) | | |\n+-------------------------------------------+------+---------------+\n| Measurements made by OS (e.g., Linux IMA) | 10 | 10 |\n+-------------------------------------------+------+---------------+", + "raw": true, + "ja": "" + }, + { + "indent": 24, + "text": "Table 1: Attested Objects", + "ja": "表1：証明されたオブジェクト" + }, + { + "indent": 0, + "text": "2.1.2. Notes on PCR Allocations", + "section_title": true, + "ja": "2.1.2. PCR割り当てに関するメモ" + }, + { + "indent": 3, + "text": "It is important to recognize that PCR[0] is critical. The first measurement into PCR[0] is taken by the Root of Trust for Measurement, which is code that, by definition, cannot be verified by measurement. This measurement establishes the chain of trust for all subsequent measurements. If the PCR[0] measurement cannot be trusted, the validity of the entire chain is called into question.", + "ja": "PCR [0]が重要であることを認識することが重要です。PCR [0]への最初の測定は、測定のために信頼のルートによって取得されます。これは、定義上、測定では検証できないコードです。この測定により、その後のすべての測定の信頼の連鎖が確立されます。PCR [0]測定値を信頼できない場合、チェーン全体の有効性が疑問視されます。" + }, + { + "indent": 3, + "text": "Distinctions between PCR[0], PCR[2], PCR[4], and PCR[8] are summarized below:", + "ja": "PCR [0]、PCR [2]、PCR [4]、およびPCR [8]の区別を以下にまとめます。" + }, + { + "indent": 3, + "text": "PCR[0]", + "ja": "PCR [0]" + }, + { + "indent": 12, + "text": "typically represents a consistent view of rarely changed boot components of the host platform, which allows Attestation policies to be defined using the less changeable components of the transitive trust chain. This PCR typically provides a consistent view of the platform regardless of user-selected options.", + "ja": "通常、ホストプラットフォームのめったに変更されていないブートコンポーネントの一貫したビューを表します。これにより、推移的な信頼チェーンのあまり変化しないコンポーネントを使用して証明ポリシーを定義できます。このPCRは通常、ユーザーが選択したオプションに関係なく、プラットフォームの一貫したビューを提供します。" + }, + { + "indent": 3, + "text": "PCR[2]", + "ja": "PCR [2]" + }, + { + "indent": 12, + "text": "is intended to represent a \"user-configurable\" environment where the user has the ability to alter the components that are measured into PCR[2]. This is typically done by adding adapter cards, etc., into user-accessible Peripheral Component Interconnect (PCI) or other slots. In UEFI systems, these devices may be configured by Option ROMs measured into PCR[2] and executed by the UEFI BIOS.", + "ja": "ユーザーがPCRに測定されるコンポーネントを変更する機能を持つ「ユーザー構成可能な」環境を表すことを目的としています[2]。これは通常、アダプターカードなどをユーザーアクセス可能な周辺コンポーネントインターコネクト（PCI）またはその他のスロットに追加することによって行われます。UEFIシステムでは、これらのデバイスは、PCR [2]に測定され、UEFI BIOSによって実行されるオプションROMによって構成されてもよい。" + }, + { + "indent": 3, + "text": "PCR[4]", + "ja": "PCR [4]" + }, + { + "indent": 12, + "text": "is intended to represent the software that manages the transition between the platform's pre-OS start and the state of a system with the OS present. This PCR, along with PCR[5], identifies the initial OS loader (e.g., GRUB for Linux).", + "ja": "プラットフォームのPre-OSスタートとOSが存在するシステムの状態との間の移行を管理するソフトウェアを表すことを目的としています。このPCRは、PCR [5]とともに、初期OSローダー（LinuxのGrubなど）を識別します。" + }, + { + "indent": 3, + "text": "PCR[8]", + "ja": "PCR [8]" + }, + { + "indent": 12, + "text": "is used by the OS loader (e.g., GRUB) to record measurements of the various components of the operating system.", + "ja": "OSローダー（GRUBなど）で使用され、オペレーティングシステムのさまざまなコンポーネントの測定値を記録します。" + }, + { + "indent": 3, + "text": "Although [PC-CLIENT-BIOS-TPM-2.0] specifies the use of the first eight PCRs very carefully to ensure interoperability among multiple UEFI BIOS vendors, it should be noted that embedded software vendors may have considerably more flexibility. Verifiers typically need to know which log entries are consequential and which are not (possibly controlled by local policies), but the Verifier may not need to know what each log entry means or why it was assigned to a particular PCR. Designers must recognize that some PCRs may cover log entries that a particular Verifier considers critical and other log entries that are not considered important, so differing PCR values may not on their own constitute a check for authenticity. For example, in a UEFI system, some administrators may consider booting an image from a removable drive, something recorded in a PCR, to be a security violation, while others might consider that operation to be an authorized recovery procedure.", + "ja": "[PC-Client-BIOS-TPM-2.0]は、複数のUEFI BIOSベンダー間の相互運用性を確保するために、最初の8つのPCRの使用を非常に慎重に指定していますが、組み込まれたソフトウェアベンダーはかなり柔軟性があることに注意する必要があります。Verifiersは通常、どのログエントリが結果的であり、どのログエントリではないかを知る必要があります（おそらくローカルポリシーによって制御されます）が、検証者は、各ログエントリが何を意味するのか、なぜ特定のPCRに割り当てられたのかを知る必要がない場合があります。設計者は、特定の検証者が重要と見なされない他のログエントリを考慮するログエントリをカバーする場合があるため、PCR値が異なる場合があることを認識しなければならないため、PCR値が異なる場合があります。たとえば、UEFIシステムでは、一部の管理者は、PCRに記録されたリムーバブルドライブから画像を起動することを検討することを検討する場合があります。" + }, + { + "indent": 3, + "text": "Designers may allocate particular events to specific PCRs in order to achieve a particular objective with local attestation (e.g., allowing a procedure to execute, or releasing a particular decryption key, only if a given PCR is in a given state). It may also be important to designers to consider whether streaming notification of PCR updates is required (see [RATS-NET-DEV-SUB]). Specific log entries can only be validated if the Verifier receives every log entry affecting the relevant PCR, so (for example) a designer might want to separate rare, high-value events, such as configuration changes, from high-volume, routine measurements such as IMA logs [IMA].", + "ja": "設計者は、特定のイベントを特定のPCRに割り当てることができます。特定の目的をローカルの証明で達成することができます（たとえば、特定のPCRが特定の状態にある場合にのみ、特定の復号化キーを実行またはリリースする手順を許可します）。また、設計者にとって、PCR更新のストリーミング通知が必要かどうかを検討することも重要かもしれません（[rats-net-dev-sub]を参照）。特定のログエントリは、検証者が関連するPCRに影響を与えるすべてのログエントリを受信した場合にのみ検証できます。たとえば、設計者は、構成変更など、大量の日常的な測定値から、希少な高価値のイベントを分離したい場合があります。IMAがログするように[IMA]。" + }, + { + "indent": 0, + "text": "2.2. RIV Keying", + "section_title": true, + "ja": "2.2. RIVキーイング" + }, + { + "indent": 3, + "text": "RIV attestation relies on two credentials:", + "ja": "RIVの証明は、2つの資格情報に依存しています。" + }, + { + "indent": 6, + "text": "* An identity key pair and matching certificate is required to certify the identity of the Attester itself. RIV specifies the use of an IEEE 802.1AR DevID [IEEE-802-1AR] that is signed by the device manufacturer and contains the device serial number. This requirement goes slightly beyond 802.1AR; see Section 2.4 for notes.", + "ja": "* Attester自体の身元を証明するには、IDキーペアとマッチング証明書が必要です。RIVは、デバイスメーカーが署名し、デバイスのシリアル番号を含むIEEE 802.1AR Devid [IEEE-802-1AR]の使用を指定します。この要件は802.1ARをわずかに超えています。メモについては、セクション2.4を参照してください。" + }, + { + "indent": 6, + "text": "* An Attestation key pair and matching certificate is required to sign the Quote generated by the TPM to report evidence of software configuration.", + "ja": "* ソフトウェア構成の証拠を報告するために、TPMによって生成された見積もりに署名するには、証明キーペアとマッチング証明書が必要です。" + }, + { + "indent": 3, + "text": "In a TPM application, both the Attestation private key and the DevID private key MUST be protected by the TPM. Depending on other TPM configuration procedures, the two keys are likely to be different; some of the considerations are outlined in the \"TPM 2.0 Keys for Device Identity and Attestation\" document [PLATFORM-DEVID-TPM-2.0].", + "ja": "TPMアプリケーションでは、ATSETATIANS秘密キーとDevID秘密鍵の両方がTPMによって保護されなければなりません。他のTPM構成手順に応じて、2つのキーが異なる可能性があります。考慮事項のいくつかは、「デバイスのアイデンティティと証明のためのTPM 2.0キー」ドキュメント[Platform-Devid-TPM-2.0]で概説されています。" + }, + { + "indent": 3, + "text": "The \"TPM 2.0 Keys for Device Identity and Attestation\" document [PLATFORM-DEVID-TPM-2.0] specifies further conventions for these keys:", + "ja": "「デバイスのアイデンティティと証明のためのTPM 2.0キー」ドキュメント[Platform-Devid-TPM-2.0]は、これらのキーのさらなる規則を指定します。" + }, + { + "indent": 6, + "text": "* When separate Identity and Attestation keys are used, the AK and its X.509 certificate should parallel the DevID, with the same unique device identification as the DevID certificate (that is, the same subject and subjectAltName (if present), even though the key pairs are different). By examining the corresponding AK certificate, the Verifier can directly link a device's quote, which was signed by an AK, to the device that provided it. If the subject in the AK certificate doesn't match the corresponding DevID certificate, or if they're signed by different authorities, the Verifier may signal the detection of an Asokan-style person-in-the-middle attack (see Section 5.2).", + "ja": "* 個別のIDと証明キーを使用する場合、AKとそのX.509証明書は、devid証明書と同じ一意のデバイス識別（つまり、同じサブジェクトとsubjectaltname（存在する場合）である場合でも、devidと並行する必要があります。ペアは異なります）。対応するAK証明書を調べることにより、検証者は、AKによって署名されたデバイスの引用を、提供したデバイスに直接リンクできます。AK証明書の被験者が対応するDevid証明書と一致しない場合、または異なる当局によって署名されている場合、検証者はアソカンスタイルの中間攻撃の検出を信号することができます（セクション5.2を参照）。" + }, + { + "indent": 6, + "text": "* Network devices that are expected to use SZTP as specified in [RFC8572] MUST be shipped by the manufacturer with pre-provisioned keys (Initial DevID and Initial AK, called IDevID and IAK, respectively). IDevID and IAK certificates MUST both be signed by the Endorser (typically the device manufacturer). Inclusion of an IDevID and IAK by a vendor does not preclude a mechanism whereby an administrator can define LDevID and Local Attestation Keys (LAK) if desired.", + "ja": "* [RFC8572]で指定されているSZTPを使用すると予想されるネットワークデバイスは、製造業者が事前に生成されたキー（初期devidおよびIdevidおよびIAKと呼ばれる初期AK）を備えた出荷する必要があります。IDEVIDとIAKの証明書は、両方ともエンドーザー（通常はデバイスメーカー）によって署名されなければなりません。ベンダーによるIDEVIDとIAKを含めることは、管理者が必要に応じてLDEVIDおよびローカル証明キー（LAK）を定義できるメカニズムを排除しません。" + }, + { + "indent": 0, + "text": "2.3. RIV Information Flow", + "section_title": true, + "ja": "2.3. RIV情報の流れ" + }, + { + "indent": 3, + "text": "RIV workflow for network equipment is organized around a simple use case where a network operator wishes to verify the integrity of software installed in specific, fielded devices. A normative taxonomy of terms is given in [RFC9334], but as a reminder, this use case implies several roles and objects:", + "ja": "ネットワーク機器のRIVワークフローは、ネットワークオペレーターが特定のフィールドデバイスにインストールされているソフトウェアの整合性を確認したい単純なユースケースを中心に編成されています。用語の規範的な分類法は[RFC9334]に与えられていますが、リマインダーとして、このユースケースはいくつかの役割とオブジェクトを意味します。" + }, + { + "indent": 3, + "text": "Attester:", + "ja": "アテスター：" + }, + { + "indent": 12, + "text": "The device that the network operator wants to examine.", + "ja": "ネットワークオペレーターが調べたいデバイス。" + }, + { + "indent": 3, + "text": "Verifier:", + "ja": "Verifier：" + }, + { + "indent": 12, + "text": "Which might be a Network Management Station and is somewhat separate from the Device that will retrieve the signed evidence and measurement logs, and analyze them to pass judgment on the security posture of the device.", + "ja": "これはネットワーク管理ステーションである可能性があり、署名された証拠と測定ログを取得し、デバイスのセキュリティ姿勢に関する判断を渡すためにそれらを分析するデバイスとは多少分離されています。" + }, + { + "indent": 3, + "text": "Relying Party:", + "ja": "頼るパーティー：" + }, + { + "indent": 12, + "text": "Can act on Attestation Results. Interaction between the Relying Party and the Verifier is considered out of scope for RIV.", + "ja": "証明の結果に基づいて行動できます。依存者と検証剤の間の相互作用は、RIVの範囲外であると見なされます。" + }, + { + "indent": 3, + "text": "Signed Reference Integrity Manifests (RIMs):", + "ja": "署名された参照整合性マニフェスト（RIMS）：" + }, + { + "indent": 12, + "text": "Contains Reference Values. RIMs can either be created by the device manufacturer and shipped along with the device as part of its software image, or alternatively, could be obtained several other ways (direct to the Verifier from the manufacturer, from a third party, from the owner's concept of a \"known good system\", etc.). Retrieving RIMs from the device itself allows attestation to be done in systems that may not have access to the public Internet, or by other devices that are not management stations per se (e.g., a peer device; see Section 3.1.3). If Reference Values are obtained from multiple sources, the Verifier may need to evaluate the relative level of trust to be placed in each source in case of a discrepancy.", + "ja": "参照値が含まれています。RIMは、デバイスメーカーによって作成され、ソフトウェアイメージの一部としてデバイスとともに出荷することも、他のいくつかの方法を取得することもできます（製造業者から、第三者から、所有者の所有者の概念から、メーカーからの検証者に直接取得できます。「既知の良いシステム」など）。デバイス自体からリムを取得することで、パブリックインターネットにアクセスできないシステムや、管理ステーション自体ではない他のデバイス（例：ピアデバイス、セクション3.1.3を参照）で証明を行うことができます。複数のソースから参照値が取得される場合、検証者は、不一致の場合に各ソースに配置される相対的な信頼レベルを評価する必要がある場合があります。" + }, + { + "indent": 3, + "text": "These components are illustrated in Figure 2.", + "ja": "これらのコンポーネントを図2に示します。" + }, + { + "indent": 3, + "text": "+----------------+ +-------------+ +---------+--------+\n|Reference Value | | Attester | Step 1 | Verifier| |\n|Provider | | (Device |<-------| (Network| Relying|\n|(Device | | under |------->| Mgmt | Party |\n|Manufacturer | | attestation)| Step 2 | Station)| |\n|or other | | | | | |\n|authority) | | | | | |\n+----------------+ +-------------+ +---------+--------+\n | /\\\n | Step 0 |\n -----------------------------------------------", + "raw": true, + "ja": "" + }, + { + "indent": 8, + "text": "Figure 2: RIV Reference Configuration for Network Equipment", + "ja": "図2：ネットワーク機器のRIV参照構成" + }, + { + "indent": 18, + "text": "Step 0: The Reference Value Provider (the device manufacturer or other authority) makes one or more RIMs, which correspond to the software image expected to be found on the device and are signed by the Reference Value Provider, available to the Verifier. (See Section 3.1.3 for \"in-band\" and \"out of band\" ways to make this happen.)", + "ja": "ステップ0：基準値プロバイダー（デバイスメーカーまたはその他の機関）は、デバイスにあると予想されるソフトウェア画像に対応し、検証者が利用できる参照値プロバイダーによって署名されます。（これを実現するための「インバンド」および「バンドから外れ」の方法については、セクション3.1.3を参照してください。）" + }, + { + "indent": 18, + "text": "Step 1: On behalf of a Relying Party, the Verifier (Network Management Station) requests DevID, Measurement Values, and possibly RIMs from the Attester.", + "ja": "ステップ1：依存している当事者に代わって、検証者（ネットワーク管理ステーション）は、devid、測定値、および場合によってはアテスターにリムを要求します。" + }, + { + "indent": 18, + "text": "Step 2: The Attester responds to the request by providing a DevID, quotes (measured values that are signed by the Attester), and optionally RIMs.", + "ja": "ステップ2：Attesterは、Devid、引用符（Attesterが署名する測定値）、およびオプションでリムを提供することにより、リクエストに応答します。" + }, + { + "indent": 3, + "text": "The use of the following standards components allows for interoperability:", + "ja": "次の標準コンポーネントを使用すると、相互運用性が可能になります。" + }, + { + "indent": 8, + "text": "1. TPM keys MUST be configured according to [PLATFORM-DEVID-TPM-2.0] or [PLATFORM-ID-TPM-1.2].", + "ja": "1. TPMキーは、[Platform-Devid-TPM-2.0]または[Platform-ID-TPM-1.2]に従って構成する必要があります。" + }, + { + "indent": 8, + "text": "2. For devices using UEFI and Linux, measurements of firmware and bootable modules MUST be taken according to \"TCG EFI Platform Specification\" [PC-CLIENT-EFI-TPM-1.2] or \"TCG PC Client Specific Platform Firmware Profile Specification\" [PC-CLIENT-BIOS-TPM-2.0], and Linux IMA [IMA].", + "ja": "2. UEFIとLinuxを使用するデバイスの場合、「TCG EFIプラットフォーム仕様」[PC-Client-EFI-TPM-1.2]または「TCG PCクライアント固有のプラットフォームファームウェアプロファイル仕様」に従ってファームウェアと起動可能なモジュールの測定値を取得する必要があります[PC-Client-BIOS-TPM-2.0]、およびLinux IMA [IMA]。" + }, + { + "indent": 8, + "text": "3. DevID MUST be managed as DevID certificates as specified in IEEE Std 802.1AR [IEEE-802-1AR], with keys protected by TPMs.", + "ja": "3. Devidは、TPMSで保護されているキーを使用して、IEEE STD 802.1AR [IEEE-802-1AR]で指定されているDevid証明書として管理する必要があります。" + }, + { + "indent": 8, + "text": "4. Attestation logs from Linux-based systems MUST be formatted according to the \"Canonical Event Log Format\" [CEL]. UEFI-based systems MUST use the TCG UEFI BIOS event log [PC-CLIENT-EFI-TPM-1.2] for TPM 1.2 systems and the \"TCG PC Client Specific Platform Firmware Profile\" [PC-CLIENT-BIOS-TPM-2.0] for TPM 2.0 systems.", + "ja": "4. Linuxベースのシステムからの証明ログは、「Canonical Event Log Format」[CEL]に従ってフォーマットする必要があります。UEFIベースのシステムは、TPM 1.2システムと「TCG PCクライアント固有のプラットフォームファームウェアプロファイル」にTCG UEFI BIOSイベントログ[PC-Client-EFI-TPM-1.2]を使用する必要があります[PC-Client-BIOS-TPM-2.0]TPM 2.0システム。" + }, + { + "indent": 8, + "text": "5. Quotes MUST be retrieved from the TPM according to the TCG Trusted Attestation Protocol Information Model (TAP IM) [TAP] and the Challenge-Response-based Remote Attestation (CHARRA) YANG model [RFC9684]. While the TAP IM gives a protocol-independent description of the data elements involved, it's important to note that quotes from the TPM are signed inside the TPM and MUST be retrieved in a way that does not invalidate the signature, to preserve the trust model. The CHARRA YANG model [RFC9684] is used for this purpose. (See Section 5, Security Considerations).", + "ja": "5. 引用は、TCG Trusted Attestation Protocol Information Model（TAP IM）[TAP]およびチャレンジ応答ベースのリモート証明（Charra）Yangモデル[RFC9684]に従ってTPMから取得する必要があります。TAP IMは、関連するデータ要素のプロトコルに依存しない説明を提供しますが、TPMからの引用はTPM内で署名されており、信頼モデルを保存するために署名を無効にしない方法で取得する必要があることに注意することが重要です。この目的には、Charra Yangモデル[RFC9684]が使用されます。（セクション5、セキュリティに関する考慮事項を参照）。" + }, + { + "indent": 8, + "text": "6. Reference Values MUST be encoded as defined in the TCG RIM document [RIM], typically using Software Identification (SWID) tags [SWID] [NIST-IR-8060] or Concise SWID (CoSWID) tags [RFC9393].", + "ja": "6. 参照値は、TCG RIMドキュメント[RIM]で定義されているようにエンコードする必要があります。通常、ソフトウェア識別（SWID）タグ[SWID] [NIST-IR-8060]または簡潔なSWID（COSWID）タグ[RFC9393]を使用する必要があります。" + }, + { + "indent": 0, + "text": "2.4. RIV Simplifying Assumptions", + "section_title": true, + "ja": "2.4. RIVの単純化仮定" + }, + { + "indent": 3, + "text": "This document makes the following simplifying assumptions to reduce complexity:", + "ja": "このドキュメントは、複雑さを減らすために次の単純化された仮定を作成します。" + }, + { + "indent": 6, + "text": "* The product to be attested MUST be shipped by the equipment vendor with both a DevID as specified by IEEE Std 802.1AR and an IAK, with certificates in place. The IAK certificate must contain the same identity information as the DevID (specifically, the same subject and subjectAltName (if used), signed by the manufacturer). The IAK is a type of key that can be used to sign a TPM Quote, but not other objects (i.e., it's marked as a TCG \"Restricted\" key; this convention is described in \"TPM 2.0 Keys for Device Identity and Attestation\" [PLATFORM-DEVID-TPM-2.0]). For network equipment, which is generally not privacy sensitive, shipping a device with both an IDevID and an IAK already provisioned substantially simplifies initial startup.", + "ja": "* 証明される製品は、IEEE STD 802.1ARで指定されているDevidとIAKの両方を使用して、証明書を設定したDevidを使用して、機器ベンダーが出荷する必要があります。IAK証明書には、Devidと同じID情報を含める必要があります（具体的には、メーカーが署名した同じ件名とsubjectaltname（使用する場合））。IAKは、TPMの見積もりに署名するために使用できるキーの一種ですが、他のオブジェクトではありません（つまり、TCG「制限付き」キーとしてマークされています。この規則は、「デバイスのアイデンティティと証明のためのTPM 2.0キー」で説明されています。Platform-Devid-TPM-2.0]）。一般的にプライバシーに敏感ではないネットワーク機器の場合、IDEVIDとIAKの両方を備えたデバイスにすでにプロビジョニングされているデバイスは、初期スタートアップを大幅に簡素化します。" + }, + { + "indent": 6, + "text": "* IEEE Std 802.1AR does not require a product serial number as part of the subject, but RIV-compliant devices MUST include their serial numbers in the DevID/IAK certificates to simplify tracking logistics for network equipment users. All other optional 802.1AR fields remain optional in RIV.", + "ja": "* IEEE STD 802.1ARは、被験者の一部として製品のシリアル番号を必要としませんが、RIVに準拠したデバイスには、ネットワーク機器ユーザーの追跡ロジスティクスを簡素化するために、DevID/IAK証明書にシリアル番号を含める必要があります。他のすべてのオプションの802.1ARフィールドは、RIVでオプションのままです。" + }, + { + "indent": 10, + "text": "It should be noted that the use of X.509 certificate fields as specified by IEEE Std 802.1AR is not identical to that described in [RFC9525] for representation of application service identity.", + "ja": "IEEE STD 802.1ARで指定されているX.509証明書フィールドの使用は、アプリケーションサービスIDを表現するために[RFC9525]で説明されているものと同一ではないことに注意してください。" + }, + { + "indent": 6, + "text": "* The product MUST be equipped with an RTM, a Root of Trust for Storage, and a Root of Trust for Reporting (as defined in [SP800-155]), which together are capable of conforming to the TCG TAP IM [TAP].", + "ja": "* この製品には、RTM、ストレージの信頼のルート、およびレポートのための信頼のルート（[SP800-155]で定義されている）を装備する必要があります。" + }, + { + "indent": 6, + "text": "* The authorized software supplier MUST make available Reference Values in the form of signed SWID or CoSWID tags.", + "ja": "* 承認されたソフトウェアサプライヤーは、署名されたSWIDまたはCosWIDタグの形で利用可能な参照値を作成する必要があります。" + }, + { + "indent": 0, + "text": "2.4.1. Reference Integrity Manifests (RIMs)", + "section_title": true, + "ja": "2.4.1. 参照整合性マニフェスト（リム）" + }, + { + "indent": 3, + "text": "[RFC9684] focuses on collecting and transmitting evidence in the form of PCR measurements and attestation logs. But the critical part of the process is enabling the Verifier to decide whether the measurements are \"the right ones\" or not.", + "ja": "[RFC9684]は、PCR測定と証明ログの形で証拠を収集および送信することに焦点を当てています。しかし、プロセスの重要な部分は、検証者が測定値が「正しいもの」であるかどうかを決定できるようにすることです。" + }, + { + "indent": 3, + "text": "While it must be up to network administrators to decide what they want on their networks, the software supplier should supply the Reference Values, in signed RIMs, that may be used by a Verifier to determine if evidence shows known good, known bad, or unknown software configurations.", + "ja": "ネットワークで何を望んでいるかを決定するのはネットワーク管理者次第でなければなりませんが、ソフトウェアサプライヤーは、証拠が既知の良い、既知の悪い、または未知の証拠が示されるかどうかを判断するために使用される署名されたリムで、参照値を署名したリムで提供する必要があります。ソフトウェア構成。" + }, + { + "indent": 3, + "text": "In general, there are two kinds of reference measurements:", + "ja": "一般的に、参照測定には2種類あります。" + }, + { + "indent": 8, + "text": "1. Measurements of early system startup (e.g., BIOS, boot loader, OS kernel) are essentially single threaded and executed exactly once, in a known sequence, before any results can be reported. In this case, while the method for computing the hash and extending relevant PCRs may be complicated, the net result is that the software (more likely, firmware) vendor will have one known good PCR value that \"should\" be present in the relevant PCRs after the box has booted. In this case, the signed reference measurement could simply list the expected hashes for the given version. However, a RIM that contains the intermediate hashes can be useful in debugging cases where the expected final hash is not the one reported.", + "ja": "1. 初期のシステムスタートアップの測定（例：BIOS、ブートローダー、OSカーネル）は、結果を報告する前に、既知のシーケンスで本質的に単一のスレッド化および実行されます。この場合、ハッシュを計算して関連するPCRを拡張する方法は複雑な場合がありますが、最終的な結果は、ソフトウェア（より可能性が高い、ファームウェア）ベンダーが、関連するPCRに「」存在する必要がある良いPCR値を持つことになることです。ボックスが起動した後。この場合、署名された参照測定は、指定されたバージョンの予想ハッシュを単純にリストすることができます。ただし、中間のハッシュを含むリムは、予想される最終的なハッシュが報告されていないケースのデバッグに役立ちます。" + }, + { + "indent": 8, + "text": "2. Measurements taken later in operation of the system, once an OS has started (for example, Linux IMA [IMA]), may be more complex, with unpredictable \"final\" PCR values. In this case, the Verifier must have enough information to reconstruct the expected PCR values from logs and signed reference measurements from a trusted authority.", + "ja": "2. OSが開始されると（Linux IMA [IMA]）、予測不可能な「最終」PCR値がある場合（たとえば、Linux IMA [IMA]）、システムの操作後に取得された測定値がより複雑になる可能性があります。この場合、検証者は、ログから予想されるPCR値を再構築し、信頼できる当局からの署名された参照測定値を再構築するのに十分な情報を持っている必要があります。" + }, + { + "indent": 3, + "text": "In both cases, the expected values can be expressed as signed SWID or CoSWID tags, but the SWID structure in the second case is somewhat more complex, as reconstruction of the extended hash in a PCR may involve thousands of files and other objects.", + "ja": "どちらの場合も、予想される値は署名されたSWIDまたはCosWIDタグとして表現できますが、PCRでの拡張ハッシュの再構築が数千のファイルや他のオブジェクトが関与する可能性があるため、2番目のケースのSWID構造はやや複雑です。" + }, + { + "indent": 3, + "text": "TCG has published an information model defining elements of RIMs under the title \"TCG Reference Integrity Manifest (RIM) Information Model\" [RIM]. This information model outlines how SWID tags should be structured to allow attestation, and it defines \"bundles\" of SWID tags that may be needed to describe a complete software release. The RIM contains metadata relating to the software release it belongs to, plus hashes for each individual file or other object that could be attested.", + "ja": "TCGは、「TCG Reference Integrity Manifest（RIM）情報モデル」というタイトルでRIMの要素を定義する情報モデルを公開しています[RIM]。この情報モデルでは、SWIDタグをどのように構成して証明を可能にするかを概説し、完全なソフトウェアリリースを説明するために必要なSWIDタグの「バンドル」を定義します。RIMには、それが属するソフトウェアリリースに関連するメタデータと、証明できる個々のファイルまたは他のオブジェクトのハッシュが含まれています。" + }, + { + "indent": 3, + "text": "Many network equipment vendors use a UEFI BIOS to launch their network operating system. These vendors may want to also use the \"TCG PC Client Reference Integrity Manifest Specification\" [PC-CLIENT-RIM], which focuses specifically on a SWID-compatible format suitable for expressing measurement values expected from a UEFI BIOS.", + "ja": "多くのネットワーク機器ベンダーは、UEFI BIOSを使用してネットワークオペレーティングシステムを起動しています。これらのベンダーは、UEFI BIOSから予想される測定値を表現するのに適したSWID互換形式に特に焦点を当てた「TCG PCクライアントリファレンスインテグリティマニフェスト仕様」[PC-Client-RIM]を使用することもできます。" + }, + { + "indent": 0, + "text": "2.4.2. Attestation Logs", + "section_title": true, + "ja": "2.4.2. 証明ログ" + }, + { + "indent": 3, + "text": "Quotes from a TPM can provide evidence of the state of a device up to the time the evidence was recorded. However, to make sense of the quote in cases where several events are extended into one PCR, an event log that identifies which software modules contributed which values to the quote during startup must also be provided. When required, the log MUST contain enough information to demonstrate its integrity by allowing exact reconstruction of the digest conveyed in the signed quote (that is, calculating the hash of all the hashes in the log should produce the same values as contained in the PCRs; if they don't match, the log may have been tampered with. See Appendix A.1).", + "ja": "TPMからの引用は、証拠が記録された時まで、デバイスの状態の証拠を提供できます。ただし、いくつかのイベントが1つのPCRに拡張される場合の引用を理解するために、起動中の引用にどのソフトウェアモジュールが寄与したかを識別するイベントログも提供する必要があります。必要に応じて、ログには、署名された引用で伝えられたダイジェストの正確な再構成を許可することにより、その完全性を示すのに十分な情報を含める必要があります（つまり、ログ内のすべてのハッシュのハッシュを計算すると、PCRSに含まれるものと同じ値が生成されるはずです。それらが一致しない場合、ログに改ざんされている可能性があります。" + }, + { + "indent": 3, + "text": "There are multiple event log formats that may be supported as viable formats of Evidence between the Attester and Verifier; however, to simplify interoperability, RIV focuses on just three:", + "ja": "AdtesterとVerifierの間で実行可能な形式の証拠としてサポートされる可能性のある複数のイベントログ形式があります。ただし、相互運用性を簡素化するために、RIVは3つだけに焦点を当てています。" + }, + { + "indent": 8, + "text": "1. TCG UEFI BIOS event log for TPM 2.0 (\"TCG PC Client Specific Platform Firmware Profile Specification\") [PC-CLIENT-BIOS-TPM-2.0]", + "ja": "1. TPM 2.0のTCG UEFI BIOSイベントログ（ \"TCG PCクライアント固有のプラットフォームファームウェアプロファイル仕様\"）[PC-Client-BIOS-TPM-2.0]" + }, + { + "indent": 8, + "text": "2. TCG UEFI BIOS event log for TPM 1.2 (\"TCG EFI Platform Specification\" for TPM Family 1.1 or 1.2, Section 7) [PC-CLIENT-EFI-TPM-1.2]", + "ja": "2. TPM 1.2のTCG UEFI BIOSイベントログ（TPMファミリー1.1または1.2、セクション7の「TCG EFIプラットフォーム仕様」）[PC-Client-EFI-TPM-1.2]" + }, + { + "indent": 8, + "text": "3. TCG \"Canonical Event Log Format\" [CEL]", + "ja": "3. TCG \"Canonical Event Log Format\" [cel]" + }, + { + "indent": 0, + "text": "3. Standards Components", + "section_title": true, + "ja": "3. 標準コンポーネント" + }, + { + "indent": 0, + "text": "3.1. Prerequisites for RIV", + "section_title": true, + "ja": "3.1. RIVの前提条件" + }, + { + "indent": 3, + "text": "The Reference Interaction Model for Challenge-Response-based Remote Attestation ([RATS-INTERACTION-MODELS]) is based on the standard roles defined in [RFC9334]. However, additional prerequisites have been established to allow for interoperable implementations of RIV use cases. These prerequisites are intended to provide sufficient context information so that the Verifier can acquire and evaluate measurements collected by the Attester.", + "ja": "チャレンジ応答ベースのリモート証明（[rats-interaction-models]）の参照相互作用モデルは、[RFC9334]で定義されている標準的な役割に基づいています。ただし、RIVユースケースの相互運用可能な実装を可能にするために、追加の前提条件が確立されています。これらの前提条件は、検証者が攻撃者によって収集された測定値を取得および評価できるように、十分なコンテキスト情報を提供することを目的としています。" + }, + { + "indent": 0, + "text": "3.1.1. Unique Device Identity", + "section_title": true, + "ja": "3.1.1. ユニークなデバイスアイデンティティ" + }, + { + "indent": 3, + "text": "A DevID in the form of a DevID certificate as specified by IEEE Std 802.1AR [IEEE-802-1AR] must be provisioned in the Attester's TPMs.", + "ja": "IEEE STD 802.1AR [IEEE-802-1AR]によって指定されているDevid証明書の形式のDevidは、AttesterのTPMSでプロビジョニングする必要があります。" + }, + { + "indent": 0, + "text": "3.1.2. Keys", + "section_title": true, + "ja": "3.1.2. キー" + }, + { + "indent": 3, + "text": "The AK and certificate must also be provisioned on the Attester according to [PLATFORM-DEVID-TPM-2.0] or [PLATFORM-ID-TPM-1.2].", + "ja": "AKと証明書は、[Platform-Devid-TPM-2.0]または[Platform-ID-TPM-1.2]に従って、Attesterにプロビジョニングする必要があります。" + }, + { + "indent": 3, + "text": "It MUST be possible for the Verifier to determine that the Attester's AKs are resident in the same TPM as its DevID keys (see Section 2.2 and Section 5, Security Considerations).", + "ja": "Verifierは、AttesterのAKがDevidキーと同じTPMに居住していることを判断することが可能である必要があります（セクション2.2およびセクション5、セキュリティに関する考慮事項を参照）。" + }, + { + "indent": 0, + "text": "3.1.3. Appraisal Policy for Evidence", + "section_title": true, + "ja": "3.1.3. 証拠に対する評価ポリシー" + }, + { + "indent": 3, + "text": "As noted in Section 2.3, the Verifier may obtain Reference Values from several sources. In addition, administrators may make authorized, site-specific changes (e.g., keys in key databases) that could impact attestation results. As such, there could be conflicts, omissions, or ambiguities between some Reference Values and collected Evidence.", + "ja": "セクション2.3で述べたように、検証者はいくつかのソースから参照値を取得する場合があります。さらに、管理者は、認定の結果に影響を与える可能性のあるサイト固有の変更（キーデータベースのキーなど）を作成する場合があります。そのため、いくつかの参照値と収集された証拠の間には、対立、省略、または曖昧さがある可能性があります。" + }, + { + "indent": 3, + "text": "The Verifier MUST have an Appraisal Policy for Evidence to evaluate the significance of any discrepancies between different reference sources, or between Reference Values and evidence from logs and quotes. While there must be an Appraisal Policy, this document does not specify the format or mechanism to convey the intended policy, nor does RIV specify mechanisms by which the results of applying the policy are communicated to the Relying Party.", + "ja": "検証者は、異なる参照ソース間の矛盾の重要性を評価するための証拠のための評価ポリシーを持っている必要があります。評価ポリシーが必要ですが、このドキュメントでは、意図したポリシーを伝えるための形式またはメカニズムを指定しておらず、RIVはポリシーを適用した結果が依存関係者に伝えられるメカニズムを指定しません。" + }, + { + "indent": 0, + "text": "3.2. Reference Model for Challenge-Response", + "section_title": true, + "ja": "3.2. チャレンジ応答の参照モデル" + }, + { + "indent": 3, + "text": "Once the prerequisites for RIV are met, a Verifier is able to acquire Evidence from an Attester. Figure 3 illustrates a RIV information flow between a Verifier and an Attester, derived from Section 7.1 of [RATS-INTERACTION-MODELS]. In this diagram, each event with its input and output parameters is shown as \"Event(input-params)=>(outputs)\". The event times shown correspond to the time types described within Appendix A of [RFC9334]:", + "ja": "RIVの前提条件が満たされると、検証剤は到達者から証拠を取得することができます。図3は、[rats-interaction-models]のセクション7.1から派生した、検証剤と攻撃者との間のRIV情報の流れを示しています。この図では、入力パラメーターと出力パラメーターを備えた各イベントは、「イベント（入力パラム）=>（出力）」として表示されます。示されているイベント時間は、[RFC9334]の付録Aに記載されている時間型に対応しています。" + }, + { + "indent": 3, + "text": ".----------. .-----------------------.\n| Attester | | Relying Party/Verifier |\n'----------' '------------------------'\n time(VG) |\ngenerateClaims(attestingEnvironment) |\n | => claims, eventLogs |\n | |\n | time(NS)\n | <-- requestAttestation(handle, authSecIDs, claimSelection) |\n | |\n time(EG) |\ncollectClaims(claims, claimSelection) |\n | => collectedClaims |\n | |\ngenerateEvidence(handle, authSecIDs, collectedClaims) |\n | => evidence |\n | time(RG,RA)\n | evidence, eventLogs -------------------------------------> |\n | |\n | appraiseEvidence(evidence, eventLogs, refValues)\n | attestationResult <= |\n | |\n ~ ~\n | time(RX)", + "raw": true, + "ja": "" + }, + { + "indent": 16, + "text": "Figure 3: IETF Attestation Information Flow", + "ja": "図3：IETF証明情報フロー" + }, + { + "indent": 3, + "text": "Step 1 (time(VG)):", + "ja": "ステップ1（時間（VG））：" + }, + { + "indent": 12, + "text": "One or more attesting network device PCRs are extended with measurements. RIV provides no direct link between the time at which the event takes place and the time that it's attested, although streaming attestation as described in [RATS-NET-DEV-SUB] could.", + "ja": "1つ以上の証明ネットワークデバイスPCRは、測定により拡張されます。RIVは、イベントが行われる時間とそれが証明された時間との間に直接リンクを提供しませんが、[rats-net-dev-sub]に記載されているストリーミングの証明はありません。" + }, + { + "indent": 3, + "text": "Step 2 (time(NS)):", + "ja": "ステップ2（時間（ns））：" + }, + { + "indent": 12, + "text": "The Verifier generates a unique random nonce (\"number used once\") and makes a request for one or more PCRs from an Attester. For interoperability, this must be accomplished as specified in \"A YANG Data Model for Challenge-Response-Based Remote Attestation (CHARRA) Procedures Using Trusted Platform Modules (TPMs)\" [RFC9684]. Both TPM 1.2 and TPM 2.0 allow nonces as large as the operative digest size (i.e., 20 or 32 bytes; see [TPM-1.2] Part 2, Section 5.5, and [TPM-2.0] Part 2, Section 10.4.4).", + "ja": "検証剤は、一意のランダムなノンセ（「1回使用される」）を生成し、agettersから1つ以上のPCRをリクエストします。相互運用性のために、これは「信頼できるプラットフォームモジュール（TPMS）を使用したチャレンジ応答ベースのリモートアテスト（CHARA）手順のYangデータモデル」[RFC9684]で指定されているように達成する必要があります。TPM 1.2とTPM 2.0の両方が、手術ダイジェストサイズと同じくらい大きいノンセスを許可します（つまり、20または32バイト。[TPM-1.2]パート2、セクション5.5、および[TPM-2.0]パート2、セクション10.4.4を参照）。" + }, + { + "indent": 3, + "text": "Step 3 (time(EG)):", + "ja": "ステップ3（時間（例））：" + }, + { + "indent": 12, + "text": "On the Attester, measured values are retrieved from the Attester's TPM. This requested PCR evidence along with the Verifier's nonce is called a Quote and is signed by the AK associated with the DevID. Quotes are retrieved according to the CHARRA YANG model [RFC9684]. At the same time, the Attester collects log evidence showing the values have been extended into that PCR. Appendix A.1 gives more detail on how this works and includes references to the structure and contents of quotes in TPM documents.", + "ja": "Attesterでは、測定値はAttesterのTPMから取得されます。これは、検証者のノンセとともに、PCRの証拠を要求し、引用と呼ばれ、Devidに関連付けられたAKによって署名されます。引用符は、Charra Yangモデル[RFC9684]に従って取得されます。同時に、Attesterは、値がそのPCRに拡張されていることを示すログの証拠を収集します。付録A.1では、これがどのように機能するかについての詳細を示し、TPMドキュメントの引用符の構造と内容への参照を含んでいます。" + }, + { + "indent": 3, + "text": "Step 4:", + "ja": "ステップ4：" + }, + { + "indent": 12, + "text": "The collected Evidence is passed from the Attester to the Verifier.", + "ja": "収集された証拠は、アテスターから検証剤に渡されます。" + }, + { + "indent": 3, + "text": "Step 5 (time(RG,RA)):", + "ja": "ステップ5（時間（RG、RA））：" + }, + { + "indent": 12, + "text": "The Verifier reviews the Evidence and takes action as needed. As the interaction between Relying Party and Verifier is out of scope for RIV, this can be described as one step.", + "ja": "Verifierは証拠を確認し、必要に応じて行動を起こします。頼る当事者と検証者の間の相互作用はRIVの範囲外であるため、これは1つのステップとして説明できます。" + }, + { + "indent": 6, + "text": "* If the signature covering TPM Evidence is not correct, the device SHOULD NOT be trusted.", + "ja": "* TPMの証拠をカバーする署名が正しくない場合、デバイスを信頼してはなりません。" + }, + { + "indent": 6, + "text": "* If the nonce in the response doesn't match the Verifier's nonce, the response may be a replay, and the device SHOULD NOT be trusted.", + "ja": "* 応答のNonCEが検証者のNonCEと一致しない場合、応答はリプレイである可能性があり、デバイスを信頼してはなりません。" + }, + { + "indent": 6, + "text": "* If the signed PCR values do not match the set of log entries that have extended a particular PCR, the device SHOULD NOT be trusted.", + "ja": "* 署名されたPCR値が特定のPCRを拡張したログエントリのセットと一致しない場合、デバイスは信頼してはなりません。" + }, + { + "indent": 6, + "text": "* If the log entries that the Verifier considers important do not match known good values, the device SHOULD NOT be trusted. We note that the process of collecting and analyzing the log can be omitted if the value in the relevant PCR is already a known-good value.", + "ja": "* Verifierが重要と見なすログエントリが既知の良い値と一致しない場合、デバイスは信頼してはなりません。関連するPCRの値がすでに既知の値である場合、ログを収集および分析するプロセスを省略できることに注意してください。" + }, + { + "indent": 6, + "text": "* If the set of log entries are not seen as acceptable by the Appraisal Policy for Evidence, the device SHOULD NOT be trusted.", + "ja": "* ログエントリのセットが証拠のための評価ポリシーで受け入れられると見なされない場合、デバイスを信頼してはなりません。" + }, + { + "indent": 6, + "text": "* If time(RG)-time(NS) is greater than the Appraisal Policy for Evidence's threshold for assessing freshness, the Evidence is considered stale and SHOULD NOT be trusted.", + "ja": "* Time（RG）-Time（NS）が新鮮さを評価するための証拠のしきい値の評価ポリシーよりも大きい場合、証拠は古く見なされ、信頼されるべきではありません。" + }, + { + "indent": 0, + "text": "3.2.1. Transport and Encoding", + "section_title": true, + "ja": "3.2.1. 輸送とエンコーディング" + }, + { + "indent": 3, + "text": "Network Management systems may retrieve signed PCR-based Evidence using NETCONF or RESTCONF with [RFC9684]. In either case, implementations must do so using a secure tunnel.", + "ja": "ネットワーク管理システムは、[RFC9684]を使用してNetConfまたはRestConfを使用して、署名されたPCRベースの証拠を取得する場合があります。どちらの場合でも、実装は安全なトンネルを使用してそうする必要があります。" + }, + { + "indent": 3, + "text": "Log Evidence MUST be retrieved via log interfaces specified in [RFC9684].", + "ja": "[RFC9684]で指定されたログインターフェイスを介して、ログ証拠を取得する必要があります。" + }, + { + "indent": 0, + "text": "3.3. Centralized vs. Peer-to-Peer", + "section_title": true, + "ja": "3.3. 集中型とピアツーピア" + }, + { + "indent": 3, + "text": "Figure 3 assumes that the Verifier is trusted, while the Attester is not. In a peer-to-peer application such as two routers negotiating a trust relationship, the two peers can each ask the other to prove software integrity. In this application, the information flow is the same, but each side plays a role both as an Attester and a Verifier. Each device issues a challenge, and each device responds to the other's challenge, as shown in Figure 4. Peer-to-peer challenges, particularly if used to establish a trust relationship between routers, require devices to carry their own signed reference measurements (RIMs). Devices may also have to carry an appraisal policy for evidence for each possible peer device so that each device has everything needed for remote attestation, without having to resort to a central authority.", + "ja": "図3は、検証剤が信頼されていると仮定していますが、攻撃はそうではありません。信頼関係を交渉する2つのルーターなどのピアツーピアアプリケーションでは、2つのピアがそれぞれソフトウェアの完全性を証明するように依頼することができます。このアプリケーションでは、情報の流れは同じですが、それぞれの側は、攻撃者と検証剤の両方として役割を果たします。各デバイスは課題を発行し、図4に示すように、各デバイスは相手の課題に応答します。特にルーター間の信頼関係を確立するために使用される場合、ピアツーピアの課題は、独自の参照測定値を運ぶためにデバイスが必要です（RIMS）。また、デバイスは、各デバイスが中央当局に頼ることなく、リモートの証明に必要なものすべてを持つように、可能な各ピアデバイスの証拠について評価ポリシーを携帯する必要がある場合があります。" + }, + { + "indent": 3, + "text": "+---------------+ +---------------+\n| RefVal | | RefVal |\n| Provider A | | Provider B |\n| Firmware | | Firmware |\n| Configuration | | Configuration |\n| Authority | | Authority |\n| | | |\n+---------------+ +---------------+\n | |\n | |Step 0B\n | +------------+ +------------+ |\n | | | Step 1 | | | \\\n | | Attester |<------>| Verifier | | |\n | | |<------>| | | | Router B\n +------>| | Step 2 | | | |- Challenges\n Step 0A| | | | | | Router A\n | |------->| | | |\n |- Router A -| Step 3 |- Router B -| | /\n | | | | |\n | | | | |\n | | Step 1 | | | \\\n | Verifier |<------>| Attester |<-+ | Router A\n | |<------>| | |- Challenges\n | | Step 2 | | | Router B\n | | | | |\n | |<-------| | |\n +------------+ Step 3 +------------+ /", + "raw": true, + "ja": "" + }, + { + "indent": 12, + "text": "Figure 4: Peer-to-Peer Attestation Information Flow", + "ja": "図4：ピアツーピアの証明情報フロー" + }, + { + "indent": 3, + "text": "In this application, each device may need to be equipped with signed RIMs to act as an Attester, and to allow each device to act as a Verifier, each may need to be equipped with an Appraisal Policy for Evidence and a selection of trusted X.509 root certificates also. An existing link layer protocol such as 802.1X [IEEE-802.1X] or 802.1AE [IEEE-802.1AE], with Evidence being enclosed over a variant of the Extensible Authentication Protocol (EAP) [RFC3748] or Link Layer Discovery Protocol (LLDP) [LLDP], are suitable methods for such an exchange. Details of peer-to-peer operation are out of scope for this document.", + "ja": "このアプリケーションでは、各デバイスに登録者として機能し、各デバイスが検証剤として機能するようにするために署名されたリムを装備する必要がある場合があります。509ルート証明書も。802.1x [IEEE-802.1x]または802.1AE [IEEE-802.1AE]などの既存のリンクレイヤープロトコル。拡張可能な認証プロトコル（EAP）[RFC3748]またはリンクレイヤー発見プロトコル（LLDPP）のバリアントに証拠が囲まれています。）[LLDP]、そのような交換に適した方法です。ピアツーピア操作の詳細は、このドキュメントの範囲外です。" + }, + { + "indent": 0, + "text": "4. Privacy Considerations", + "section_title": true, + "ja": "4. プライバシーに関する考慮事項" + }, + { + "indent": 3, + "text": "Network equipment, such as routers, switches, and firewalls, has a key role to play in guarding the privacy of individuals using the network. Network equipment generally adheres to several rules to protect privacy:", + "ja": "ルーター、スイッチ、ファイアウォールなどのネットワーク機器は、ネットワークを使用して個人のプライバシーを守る上で重要な役割を果たします。ネットワーク機器は一般に、プライバシーを保護するためにいくつかのルールを順守します。" + }, + { + "indent": 6, + "text": "* Packets passing through the device must not be sent to unauthorized destinations. For example:", + "ja": "* デバイスを通過するパケットを不正な宛先に送信しないでください。例えば：" + }, + { + "indent": 12, + "text": "- Routers often act as Policy Enforcement Points, where individual subscribers may be checked for authorization to access a network. Subscriber login information must not be released to unauthorized parties.", + "ja": "- 多くの場合、ルーターはポリシー執行ポイントとして機能し、個々のサブスクライバーにネットワークにアクセスする許可を確認できます。サブスクライバーのログイン情報は、不正な当事者にリリースされてはなりません。" + }, + { + "indent": 12, + "text": "- Network equipment is often called upon to block access to protected resources from unauthorized users.", + "ja": "- ネットワーク機器は、許可されていないユーザーから保護されたリソースへのアクセスをブロックするためにしばしば求められています。" + }, + { + "indent": 6, + "text": "* Routing information, such as the identity of a router's peers, must not be leaked to unauthorized neighbors.", + "ja": "* ルーターの仲間の身元などのルーティング情報は、不正な隣人に漏れてはなりません。" + }, + { + "indent": 6, + "text": "* If configured, encryption and decryption of traffic must be carried out reliably, while protecting keys and credentials.", + "ja": "* 構成されている場合、キーと資格情報を保護しながら、トラフィックの暗号化と復号化を確実に実行する必要があります。" + }, + { + "indent": 3, + "text": "Functions that protect privacy are implemented as part of each layer of hardware and software that makes up the networking device. In light of these requirements for protecting the privacy of users of the network, the network equipment must identify itself, and its boot configuration and measured device state (for example, PCR values), to the equipment's administrator so there's no uncertainty about the device's function and configuration. Attestation is a component that allows the administrator to ensure that the network provides individual and peer privacy guarantees, even though the device itself may not have a right to keep its identity secret.", + "ja": "プライバシーを保護する機能は、ネットワークデバイスを構成するハードウェアとソフトウェアの各レイヤーの一部として実装されます。ネットワークのユーザーのプライバシーを保護するためのこれらの要件に照らして、ネットワーク機器はそれ自体とそのブート構成と測定されたデバイス状態（PCR値など）を機器の管理者に識別する必要があるため、デバイスの機能に関する不確実性はありませんおよび構成。証明は、デバイス自体にアイデンティティを秘密にする権利がない場合でも、管理者がネットワークが個人およびピアプライバシーの保証を提供できるようにするコンポーネントです。" + }, + { + "indent": 3, + "text": "See [NET-EQ] for more context on privacy in networking devices.", + "ja": "ネットワーキングデバイスのプライバシーに関するより多くのコンテキストについては、[net-eq]を参照してください。" + }, + { + "indent": 3, + "text": "While attestation information from network devices is not likely to contain privacy-sensitive content regarding network users, administrators may want to keep attestation records confidential to avoid disclosing versions of software loaded on the device, which is information that could facilitate attacks against known vulnerabilities.", + "ja": "ネットワークデバイスからの証明情報には、ネットワークユーザーに関するプライバシーに敏感なコンテンツが含まれている可能性は低いですが、管理者は、既知の脆弱性に対する攻撃を促進できる情報であるデバイスにロードされたソフトウェアのバージョンの開示バージョンを避けるために、機密記録を保持したい場合があります。" + }, + { + "indent": 0, + "text": "5. Security Considerations", + "section_title": true, + "ja": "5. セキュリティに関する考慮事項" + }, + { + "indent": 3, + "text": "Specifications such as TLS [RFC8446] and YANG [RFC7950] contain considerable advice on keeping network-connected systems secure. This section outlines specific risks and mitigations related to attestation.", + "ja": "TLS [RFC8446]やYang [RFC7950]などの仕様には、ネットワーク接続システムを安全に保つことに関するかなりのアドバイスが含まれています。このセクションでは、認証に関連する特定のリスクと緩和の概要を説明します。" + }, + { + "indent": 3, + "text": "Attestation Evidence obtained by the RIV procedure is subject to a number of attacks:", + "ja": "RIV手順によって得られた証明の証拠は、多くの攻撃の対象となります。" + }, + { + "indent": 6, + "text": "* Keys may be compromised.", + "ja": "* キーが損なわれる可能性があります。" + }, + { + "indent": 6, + "text": "* A counterfeit device may attempt to impersonate (spoof) a known authentic device.", + "ja": "* 偽造デバイスは、既知の本物のデバイスになりすます（スプーフィング）を試みる場合があります。" + }, + { + "indent": 6, + "text": "* Person-in-the-middle attacks may be used by a compromised device to attempt to deliver responses that originate in an authentic device.", + "ja": "* 中間の攻撃は、妥協したデバイスによって使用されて、本物のデバイスに由来する応答を提供しようとすることができます。" + }, + { + "indent": 6, + "text": "* Replay attacks may be attempted by a compromised device.", + "ja": "* リプレイ攻撃は、侵害されたデバイスによって試行される場合があります。" + }, + { + "indent": 0, + "text": "5.1. Keys Used in RIV", + "section_title": true, + "ja": "5.1. RIVで使用されるキー" + }, + { + "indent": 3, + "text": "Trustworthiness of RIV attestation depends strongly on the validity of keys used for identity and attestation reports. RIV takes full advantage of TPM capabilities to ensure that evidence can be trusted.", + "ja": "RIVの証明の信頼性は、アイデンティティと証明レポートに使用されるキーの妥当性に強く依存します。RIVは、TPM機能を最大限に活用して、証拠を信頼できることを確認します。" + }, + { + "indent": 3, + "text": "Two sets of key pairs are relevant to RIV attestation:", + "ja": "2セットのキーペアは、RIVの証明に関連しています。" + }, + { + "indent": 6, + "text": "* A DevID key pair is used to certify the identity of the device in which the TPM is installed.", + "ja": "* DevIDキーペアは、TPMがインストールされているデバイスのIDを認定するために使用されます。" + }, + { + "indent": 6, + "text": "* An AK key pair is used to certify attestation Evidence (i.e., quotes) and to provide evidence for integrity of the device software.", + "ja": "* AKキーペアは、証明の証拠（すなわち、引用）を証明し、デバイスソフトウェアの整合性の証拠を提供するために使用されます。" + }, + { + "indent": 3, + "text": "TPM practices usually require that these keys be different to ensure that a general-purpose signing key cannot be used to spoof an attestation quote.", + "ja": "TPMプラクティスでは、通常、これらのキーが異なることを要求して、一般的な署名キーを使用して証明の見積もりをスプーフィングできないことを確認します。" + }, + { + "indent": 3, + "text": "In each case, the private half of the key is known only to the TPM and cannot be retrieved externally, even by a trusted party. To ensure that's the case, specification-compliant private/public key pairs are generated inside the TPM, where they are never exposed and cannot be extracted (see [PLATFORM-DEVID-TPM-2.0]).", + "ja": "いずれの場合も、キーのプライベートハーフはTPMにのみ知られており、信頼できる当事者であっても外部から取得することはできません。それを確実にするために、仕様に準拠したプライベート/公開キーのペアがTPM内で生成され、そこで露出せず、抽出できません（[プラットフォーム-Devid-TPM-2.0を参照]）。" + }, + { + "indent": 3, + "text": "Keeping keys safe is a critical enabler of trustworthiness, but it's just part of attestation security; knowing which keys are bound to the device in question is just as important in an environment where private keys are never exposed.", + "ja": "キーを安全に保つことは、信頼性の重要なイネーブラーですが、それは証明のセキュリティの一部にすぎません。どのキーが問題のデバイスにバインドされているかを知ることは、プライベートキーが決して露出しない環境でも同様に重要です。" + }, + { + "indent": 3, + "text": "While there are many ways to manage keys in a TPM (see [PLATFORM-DEVID-TPM-2.0]), RIV includes support for \"zero touch\" provisioning (also known as zero touch onboarding) of fielded devices (e.g., SZTP [RFC8572]), where keys that have predictable trust properties are provisioned by the device vendor.", + "ja": "TPMでキーを管理する方法はたくさんありますが（[プラットフォーム-Devid-TPM-2.0]を参照）、RIVにはフィールドデバイスの「ゼロタッチ」プロビジョニング（ゼロタッチオンボーディングとも呼ばれます）のサポートが含まれています（例えば、SZTP [RFC85722]）、予測可能な信頼プロパティを持つキーがデバイスベンダーによってプロビジョニングされます。" + }, + { + "indent": 3, + "text": "Device identity in RIV is based on DevID defined by IEEE Std 802.1AR. This specification provides several elements:", + "ja": "RIVのデバイスアイデンティティは、IEEE STD 802.1ARによって定義されたDevidに基づいています。この仕様はいくつかの要素を提供します。" + }, + { + "indent": 6, + "text": "* A DevID requires a unique key pair for each device, accompanied by an X.509 certificate.", + "ja": "* devidには、x.509証明書を添付するデバイスごとに一意のキーペアが必要です。" + }, + { + "indent": 6, + "text": "* The private portion of the DevID key is to be stored in the device, in a manner that provides confidentiality (Section 6.2.5 of [IEEE-802-1AR]).", + "ja": "* Devidキーの私的部分は、機密性を提供する方法でデバイスに保存されます（[IEEE-802-1AR]のセクション6.2.5）。" + }, + { + "indent": 3, + "text": "The X.509 certificate contains several components:", + "ja": "X.509証明書にはいくつかのコンポーネントが含まれています。" + }, + { + "indent": 6, + "text": "* The public part of the unique DevID key assigned to that device allows a challenge of identity.", + "ja": "* そのデバイスに割り当てられた一意のdevidキーの公開部分は、アイデンティティの課題を可能にします。" + }, + { + "indent": 6, + "text": "* An identifying string that's unique to the manufacturer of the device. This is normally the serial number of the unit, which might also be printed on a label on the device.", + "ja": "* デバイスのメーカーに固有の識別文字列。これは通常、ユニットのシリアル番号であり、デバイス上のラベルにも印刷される場合があります。" + }, + { + "indent": 6, + "text": "* The certificate must be signed by a key traceable to the manufacturer's root key.", + "ja": "* 証明書は、メーカーのルートキーに追跡可能なキーによって署名する必要があります。" + }, + { + "indent": 3, + "text": "With these elements, the device's manufacturer and serial number can be identified by analyzing the DevID certificate plus the chain of intermediate certificates leading back to the manufacturer's root certificate. As is conventional in TLS or SSH connections, a random nonce must be signed by the device in response to a challenge, proving possession of its DevID private key.", + "ja": "これらの要素を使用すると、デバイスのメーカーとシリアル番号は、DevID証明書に加えて、メーカーのルート証明書に戻る中間証明書のチェーンを分析することで識別できます。TLSまたはSSH接続では従来のように、課題に応じてデバイスによってランダムなノンセに署名する必要があり、DevID秘密キーの所有を証明する必要があります。" + }, + { + "indent": 3, + "text": "RIV uses the DevID to validate a TLS or SSH connection to the device as the attestation session begins. Security of this process derives from TLS or SSH security, with the DevID, which contains a device serial number, providing proof that the session terminates on the intended device. See [RFC8446] [RFC4253].", + "ja": "RIVは、Devidを使用して、証明セッションが開始されるときにTLSまたはSSH接続をデバイスに検証します。このプロセスのセキュリティは、デバイスのシリアル番号を含むDevidを使用して、TLSまたはSSHセキュリティから派生し、セッションが意図したデバイスで終了することを証明します。[RFC8446] [RFC4253]を参照してください。" + }, + { + "indent": 3, + "text": "Evidence of software integrity is delivered in the form of a quote that is signed by the TPM itself and accompanied by an IAK certificate containing the same identity information as the DevID. Because the contents of the quote are signed inside the TPM, any external modification (including reformatting to a different data format) after measurements have been taken will be detected as tampering. An unbroken chain of trust is essential for ensuring that blocks of code that are taking measurements have been verified before execution (see Figure 1).", + "ja": "ソフトウェアの整合性の証拠は、TPM自体によって署名され、DevIDと同じID情報を含むIAK証明書が添付されている引用の形で配信されます。見積もりの内容はTPM内で署名されているため、測定が行われた後、外部変更（異なるデータ形式への再フォーマットを含む）が改ざんされたものとして検出されます。壊れていない信頼の連鎖は、測定を行っているコードブロックが実行前に検証されていることを確認するために不可欠です（図1を参照）。" + }, + { + "indent": 3, + "text": "Requiring measurements of the operating software to be signed by a key known only to the TPM also removes the need to trust the device's operating software (beyond the first measurement in the RTM; see below). If malicious software makes any changes to a quote in the device itself, or in the path back to the Verifier, the signature on the quote will be invalidated.", + "ja": "TPMにのみ既知のキーによって署名されるようにオペレーティングソフトウェアの測定が必要になると、デバイスのオペレーティングソフトウェアを信頼する必要性も削除されます（RTMの最初の測定を超えて、以下を参照）。悪意のあるソフトウェアがデバイス自体の見積もり、または検証器に戻るパスに変更を加えた場合、引用符の署名は無効になります。" + }, + { + "indent": 3, + "text": "A critical feature of the YANG model described in [RFC9684] is the ability to carry TPM data structures in their TCG-defined format, without requiring any changes to the structures as they were signed and delivered by the TPM. While alternate methods of conveying TPM quotes could reduce redundant information, or add another layer of signing using external keys, the implementation MUST preserve the TPM signing so that tampering anywhere in the path between the TPM itself and the Verifier can be detected.", + "ja": "[RFC9684]で説明されているYangモデルの重要な特徴は、TPMが署名および配信された構造に変更を必要とせずに、TCG定義形式でTPMデータ構造を運ぶ機能です。TPMの引用符を伝える代替方法は、冗長な情報を減らすか、外部キーを使用して署名の別のレイヤーを追加する可能性がありますが、実装はTPM自体と検証者の間のパスのどこにでも改ざんするようにTPMの署名を保持する必要があります。" + }, + { + "indent": 0, + "text": "5.2. Prevention of Spoofing and Person-in-the-Middle Attacks", + "section_title": true, + "ja": "5.2. スプーフィングと中間者攻撃の防止" + }, + { + "indent": 3, + "text": "Prevention of spoofing attacks against attestation systems is also important. There are several cases to consider:", + "ja": "認証システムに対するスプーフィング攻撃の防止も重要です。考慮すべきいくつかのケースがあります：" + }, + { + "indent": 6, + "text": "* The entire device could be spoofed. If the Verifier goes to appraise a specific Attester, it might be redirected to a different Attester.", + "ja": "* デバイス全体をスプーフィングできます。検証者が特定の攻撃を評価する場合、別の攻撃にリダイレクトされる可能性があります。" + }, + { + "indent": 6, + "text": "* A compromised device could have a valid DevID, but substitute a quote from a known-good device instead of returning its own, as described in [RFC6813].", + "ja": "* 侵害されたデバイスには有効な開発がありますが、[RFC6813]に記載されているように、独自のものを返す代わりに、既知の優れたデバイスからの引用を代用します。" + }, + { + "indent": 6, + "text": "* A device with a compromised OS could return a fabricated quote providing spoofed attestation Evidence.", + "ja": "* OSが侵害されたデバイスは、スプーフィングされた証拠の証拠を提供する製造された引用を返す可能性があります。" + }, + { + "indent": 3, + "text": "Use of the 802.1AR DevID in the TPM provides protection against the case of a spoofed device by ensuring that the Verifier's TLS or SSH session is in fact terminating on the right device.", + "ja": "TPMで802.1AR Devidを使用すると、検証者のTLSまたはSSHセッションが実際に適切なデバイスで終了していることを確認することにより、スプーフィングされたデバイスの場合に対する保護を提供します。" + }, + { + "indent": 3, + "text": "Protection against spoofed quotes from a device with valid identity is a bit more complex. An identity key must be available to sign any kind of nonce or hash offered by the Verifier, and consequently, could be used to sign a fabricated quote. To block a spoofed Attestation Result, the quote generated inside the TPM must be signed by a key, known as an AK, that's different from the DevID.", + "ja": "有効なアイデンティティを持つデバイスからのスプーフィングされた引用に対する保護は、もう少し複雑です。Verifierが提供するあらゆる種類のNONCEまたはハッシュに署名するためにIDキーを使用できる必要があります。その結果、製造された見積に署名するために使用できます。スプーフィングされた証明の結果をブロックするには、TPM内で生成された引用は、Devidとは異なるAKとして知られるキーによって署名する必要があります。" + }, + { + "indent": 3, + "text": "Given separate Attestation and DevID keys, the binding between the AK and the same device must also be proven to prevent a person-in-the-middle attack (e.g., the \"Asokan Attack\" [RFC6813]).", + "ja": "個別の証明とDevidキーを考えると、AKと同じデバイスの間の結合も、中間の攻撃を防ぐために証明する必要があります（例：「Asokan Attack」[RFC6813]）。" + }, + { + "indent": 3, + "text": "This is accomplished in RIV through use of an AK certificate with the same elements as the DevID (same manufacturer's serial number and signed by the same manufacturer's key), but containing the device's unique AK public key instead of the DevID public key. This binding between DevID and AK certificates is critical to reliable attestation.", + "ja": "これは、Devidと同じ要素を持つAK証明書を使用してRIVで達成されます（同じメーカーのシリアル番号と同じメーカーのキーで署名）が、Devid公開キーの代わりにデバイスのユニークなAK公開キーが含まれています。DevIDとAK証明書の間のこの拘束力は、信頼できる証明にとって重要です。" + }, + { + "indent": 3, + "text": "The TCG document \"TPM 2.0 Keys for Device Identity and Attestation\" [PLATFORM-DEVID-TPM-2.0] specifies OIDs for Attestation Certificates that allow the CA to mark a key as specifically known to be an AK.", + "ja": "TCGドキュメント「TPM 2.0デバイスのアイデンティティと証明のためのキー」[Platform-Devid-TPM-2.0]は、CAがAKであることが特別に知られているようにキーをマークすることを認める証明書のOIDを指定します。" + }, + { + "indent": 3, + "text": "These two key pairs and certificates are used together:", + "ja": "これらの2つの重要なペアと証明書は一緒に使用されます。" + }, + { + "indent": 6, + "text": "* The DevID is used to validate a TLS connection terminating on the device with a known serial number.", + "ja": "* DevIDは、既知のシリアル番号を使用してデバイス上で終了するTLS接続を検証するために使用されます。" + }, + { + "indent": 6, + "text": "* The AK is used to sign attestation quotes, which provides proof that the attestation evidence comes from the same device.", + "ja": "* AKは、証明の証拠が同じデバイスから得られることの証拠を提供する証明の引用に署名するために使用されます。" + }, + { + "indent": 0, + "text": "5.3. Replay Attacks", + "section_title": true, + "ja": "5.3. リプレイ攻撃" + }, + { + "indent": 3, + "text": "Replay attacks, where the results of a previous attestation are submitted in response to subsequent requests, are usually prevented by the inclusion of a random nonce in the request to the TPM for a quote. Each request from the Verifier includes a new random number (a nonce). The resulting quote signed by the TPM contains the same nonce, which allows the Verifier to determine freshness (i.e., that the resulting quote was generated in response to the Verifier's specific request). \"Time-Based Uni-Directional Attestation\" [RATS-TUDA] provides an alternate mechanism to verify freshness without requiring a request/response cycle.", + "ja": "以前の証明の結果がその後のリクエストに応じて提出されるリプレイ攻撃は、通常、見積もりのためにTPMへの要求にランダムな非CEを含めることにより防止されます。検証器からの各要求には、新しい乱数（nonce）が含まれます。TPMによって署名された結果の引用には、同じノンセが含まれているため、検証者は新鮮さを決定できます（つまり、結果の引用が検証剤の特定の要求に応じて生成されたことです）。「時間ベースの一方向の証明」[RATS-TUDA]は、要求/応答サイクルを必要とせずに鮮度を検証する代替メカニズムを提供します。" + }, + { + "indent": 0, + "text": "5.4. Owner-Signed Keys", + "section_title": true, + "ja": "5.4. 所有者に署名したキー" + }, + { + "indent": 3, + "text": "Although device manufacturers must pre-provision devices with easily verified DevID and AK certificates if SZTP such as described in [RFC8572] is to be supported, use of those credentials is not mandatory. IEEE Std 802.1AR incorporates the idea of an IDevID, which is provisioned by the manufacturer, and a LDevID, which is provisioned by the owner of the device. RIV and [PLATFORM-DEVID-TPM-2.0] extend that concept by defining an IAK and LAK with the same properties.", + "ja": "[RFC8572]に記載されているようなSZTPがサポートされる場合、デバイスメーカーは簡単に検証されたDevidおよびAK証明書を使用して、簡単に検証されたDevidおよびAK証明書を使用する必要がありますが、これらの資格情報の使用は必須ではありません。IEEE STD 802.1ARには、メーカーによってプロビジョニングされたIDEVIDのアイデアと、デバイスの所有者によってプロビジョニングされているLDEVIDのアイデアが組み込まれています。RIVと[Platform-Devid-TPM-2.0]は、同じプロパティでIAKとLAKを定義することにより、その概念を拡張します。" + }, + { + "indent": 3, + "text": "Device owners can use any method to provision the local credentials.", + "ja": "デバイスの所有者は、任意の方法を使用してローカル資格情報をプロビジョニングできます。" + }, + { + "indent": 6, + "text": "* The TCG document [PLATFORM-DEVID-TPM-2.0] shows how the IAKs can be used to certify LDevID and LAK keys. The use of the LDevID and LAK allows the device owner to use a uniform identity structure across device types from multiple manufacturers (in the same way that an \"Asset Tag\" is used by many enterprises to identify devices they own). The TCG document [PROV-TPM-2.0] also contains guidance on provisioning local identity keys in TPM 2.0. Owners should follow the same practice of binding LDevID and LAK as the manufacturer would for IDevID and IAK. See Section 2.2.", + "ja": "* TCGドキュメント[Platform-Devid-TPM-2.0]は、IAKを使用してLDEVIDおよびLAKキーを証明する方法を示しています。LDEVIDとLAKを使用すると、デバイスの所有者は、複数のメーカーのデバイスタイプ全体で均一なアイデンティティ構造を使用できます（多くの企業が所有するデバイスを特定するために「アセットタグ」が使用されるのと同じ方法で）。TCGドキュメント[Prov-TPM-2.0]には、TPM 2.0のローカルIDキーのプロビジョニングに関するガイダンスも含まれています。所有者は、メーカーがIDEVIDとIAKの場合と同じLDEVIDとLAKを拘束するのと同じ慣行に従う必要があります。セクション2.2を参照してください。" + }, + { + "indent": 6, + "text": "* Device owners, however, can use any other mechanism they want, including physical inspection and programming in a secure location, to assure themselves that local identity certificates are inserted into the intended device if they prefer to avoid placing trust in the manufacturer-provided keys.", + "ja": "* ただし、デバイスの所有者は、安全な場所での物理的検査やプログラミングなど、他のメカニズムを使用して、メーカーが提供するキーに信頼を置かないようにすることを好む場合、ローカルID証明書が意図したデバイスに挿入されることを保証することができます。" + }, + { + "indent": 3, + "text": "Clearly, local keys can't be used for SZTP; installation of the local keys can only be done by some process that runs before the device is installed for network operation, or by using procedures such as those outlined in Bootstrapping Remote Secure Key Infrastructure (BRSKI) [RFC8995].", + "ja": "明らかに、ローカルキーはSZTPには使用できません。ローカルキーのインストールは、ネットワーク操作のためにデバイスがインストールされる前に実行されるプロセス、またはリモートセキュアなキーインフラストラクチャ（BRSKI）[RFC8995]で概説されている手順などの手順を使用することによってのみ実行できます。" + }, + { + "indent": 3, + "text": "On the other end of the device lifecycle, provision should be made to wipe local keys when a device is decommissioned to indicate that the device is no longer owned by the enterprise. The manufacturer's initial identity keys must be preserved, as they contain no information that's not already printed on the device's serial number plate.", + "ja": "デバイスライフサイクルのもう一方の端では、デバイスが廃止されている場合は、デバイスがエンタープライズによって所有されなくなったことを示すためにローカルキーを拭くために提供する必要があります。メーカーの最初のIDキーは、デバイスのシリアルナンバープレートにまだ印刷されていない情報が含まれていないため、保存する必要があります。" + }, + { + "indent": 0, + "text": "5.5. Other Factors for Trustworthy Operation", + "section_title": true, + "ja": "5.5. 信頼できる操作のためのその他の要因" + }, + { + "indent": 3, + "text": "In addition to the trustworthy provisioning of keys, RIV depends on a number of other factors for trustworthy operation.", + "ja": "キーの信頼できるプロビジョニングに加えて、RIVは信頼できる操作のための他の多くの要因に依存します。" + }, + { + "indent": 6, + "text": "* Secure identity depends on mechanisms to prevent per-device secret keys from being compromised. The TPM provides this capability as a Root of Trust for Storage.", + "ja": "* 安全なアイデンティティは、デバイスごとの秘密キーが侵害されないようにするメカニズムに依存します。TPMは、ストレージの信頼のルートとしてこの機能を提供します。" + }, + { + "indent": 6, + "text": "* Attestation depends on an unbroken chain of measurements, starting from the very first measurement. See Appendix A.1 for background on TPM practices.", + "ja": "* 証明は、最初の測定から始まる壊れていない一連の測定に依存します。TPMプラクティスの背景については、付録A.1を参照してください。" + }, + { + "indent": 6, + "text": "* That first measurement is made by code called the RTM, typically done by trusted firmware stored in boot flash. Mechanisms for maintaining the trustworthiness of the RTM are out of scope for RIV, but could include immutable firmware, signed updates, or a vendor-specific hardware verification technique. See Appendix A.2 for background on Roots of Trust.", + "ja": "* その最初の測定は、通常、ブートフラッシュに保存されている信頼できるファームウェアによって行われるRTMと呼ばれるコードによって行われます。RTMの信頼性を維持するためのメカニズムは、RIVの範囲外ですが、不変のファームウェア、署名された更新、またはベンダー固有のハードウェア検証手法を含めることができます。Roots of Trustの背景については、付録A.2を参照してください。" + }, + { + "indent": 6, + "text": "* The device owner SHOULD provide some level of physical defense for the device. If a TPM that has already been programmed with an authentic DevID is stolen and is inserted into a counterfeit device, attestation of that counterfeit device may become indistinguishable from an authentic device.", + "ja": "* デバイスの所有者は、デバイスにある程度の物理的防御を提供する必要があります。すでに本物のDevidでプログラムされているTPMが盗まれ、偽造デバイスに挿入されている場合、その偽造デバイスの証明は、本物のデバイスと区別できない場合があります。" + }, + { + "indent": 3, + "text": "RIV also depends on reliable Reference Values, as expressed by the RIM [RIM]. The definition of trust procedures for RIMs is out of scope for RIV, and the device owner is free to use any policy to validate a set of reference measurements. It should also be noted that, while RIV can provide a reliable indication that a known software package is in use by the device and that the package has not been tampered with, it is the device owner's responsibility to determine that it's the correct package for the application.", + "ja": "RIVは、RIM [RIM]で表されるように、信頼できる参照値にも依存します。RIMSの信頼手順の定義はRIVの範囲外であり、デバイスの所有者は、あらゆるポリシーを使用して一連の参照測定値を検証できます。また、RIVは、既知のソフトウェアパッケージがデバイスによって使用されていること、およびパッケージが改ざんされていないという信頼できる兆候を提供できるが、それがそれが正しいパッケージであると判断することはデバイスの所有者の責任であることに注意する必要がありますが、それは注意する必要があります。応用。" + }, + { + "indent": 3, + "text": "RIMs may be conveyed either out-of-band or in-band as part of the attestation process (see Section 3.1.3). However, for network devices, where software is usually shipped as a self-contained package, RIMs signed by the manufacturer and delivered in-band may be more convenient for the device owner.", + "ja": "リムは、証明プロセスの一部として、帯域外または帯域内のいずれかを伝えることができます（セクション3.1.3を参照）。ただし、通常、ソフトウェアが自己完結型パッケージとして出荷されるネットワークデバイスの場合、メーカーが署名し、インバンド内で配信されるリムは、デバイスの所有者にとってより便利な場合があります。" + }, + { + "indent": 3, + "text": "The validity of RIV attestation results is also influenced by procedures used to create Reference Values:", + "ja": "RIVの認証結果の妥当性は、参照値を作成するために使用される手順の影響も受けます。" + }, + { + "indent": 6, + "text": "* While the RIM itself is signed, supply chains SHOULD be carefully scrutinized to ensure that the values are not subject to unexpected manipulation prior to signing. Insider attacks against code bases and build chains are particularly hard to spot.", + "ja": "* リム自体に署名されている間、サプライチェーンは、署名前に値が予期しない操作の対象ではないことを確認するために慎重に精査する必要があります。コードベースとビルドチェーンに対するインサイダー攻撃を見つけるのは特に困難です。" + }, + { + "indent": 6, + "text": "* Designers SHOULD guard against hash collision attacks. RIMs often give hashes for large objects of indeterminate size. If one of the measured objects can be replaced with an implant engineered to produce the same hash, RIV will be unable to detect the substitution. TPM 1.2 only uses SHA-1 hashes, which have been shown to be susceptible to collision attack. TPM 2.0 will produce quotes with SHA-256, which so far has resisted such attacks. Consequently, RIV implementations SHOULD use TPM 2.0.", + "ja": "* デザイナーは、ハッシュ衝突攻撃を防ぐ必要があります。リムは、しばしば不定サイズの大きなオブジェクトにハッシュを与えます。測定されたオブジェクトの1つを、同じハッシュを生成するように設計されたインプラントに置き換えることができる場合、RIVは置換を検出できません。TPM 1.2は、衝突攻撃の影響を受けやすいことが示されているSHA-1ハッシュのみを使用します。TPM 2.0は、SHA-256で引用符を作成します。これは、これまでこのような攻撃に抵抗しています。したがって、RIVの実装はTPM 2.0を使用する必要があります。" + }, + { + "indent": 0, + "text": "6. IANA Considerations", + "section_title": true, + "ja": "6. IANAの考慮事項" + }, + { + "indent": 3, + "text": "This document has no IANA actions.", + "ja": "このドキュメントにはIANAアクションがありません。" + }, + { + "indent": 0, + "text": "7. Conclusion", + "section_title": true, + "ja": "7. 結論" + }, + { + "indent": 3, + "text": "TCG technologies can play an important part in the implementation of RIV. Standards for many of the components needed for implementation of RIV already exist:", + "ja": "TCGテクノロジーは、RIVの実装において重要な役割を果たすことができます。RIVの実装に必要な多くのコンポーネントの標準はすでに存在しています。" + }, + { + "indent": 6, + "text": "* Platform identity can be based on IEEE 802.1AR DevID, coupled with careful supply-chain management by the manufacturer.", + "ja": "* プラットフォームのアイデンティティは、IEEE 802.1AR Devidに基づいて、メーカーによる慎重な供給鎖管理と組み合わせています。" + }, + { + "indent": 6, + "text": "* Complex supply chains can be certified using TCG Platform Certificates [PLATFORM-CERTS].", + "ja": "* 複雑なサプライチェーンは、TCGプラットフォーム証明書[Platform-Certs]を使用して認定できます。" + }, + { + "indent": 6, + "text": "* The TCG TAP mechanism coupled with [RFC9684] can be used to retrieve attestation evidence.", + "ja": "* [RFC9684]と組み合わせたTCG TAPメカニズムを使用して、証拠の証拠を取得できます。" + }, + { + "indent": 6, + "text": "* Reference Values must be conveyed from the software authority (e.g., the manufacturer) in RIMs to the system in which verification will take place. IETF and TCG SWID and CoSWID work ([RFC9393] [RIM]) forms the basis for this function.", + "ja": "* 参照値は、RIMSのソフトウェア機関（メーカーなど）から、検証が行われるシステムに伝えられる必要があります。IETFおよびTCG SWIDおよびCOSWIDワーク（[RFC9393] [RIM]）は、この関数の基礎を形成します。" + }, + { + "indent": 0, + "text": "8. References", + "section_title": true, + "ja": "8. 参考文献" + }, + { + "indent": 0, + "text": "8.1. Normative References", + "section_title": true, + "ja": "8.1. 引用文献" + }, + { + "indent": 3, + "text": "[CEL] Trusted Computing Group, \"Canonical Event Log Format\",\n Version 1.0, Revision 0.41, February 2022,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[IEEE-802-1AR]\n IEEE, \"IEEE Standard for Local and Metropolitan Area\n Networks - Secure Device Identity\", IEEE Std 802.1AR-2018,\n DOI 10.1109/IEEESTD.2018.8423794, August 2018,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[IMA] The kernel development community, \"dm-ima\", Linux Kernel\n 6.11, 15 September 2024,\n . The latest version can be found at\n https://docs.kernel.org/admin-guide/device-mapper/dm-\n ima.html.", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[PC-CLIENT-BIOS-TPM-2.0]\n Trusted Computing Group, \"TCG PC Client Specific Platform\n Firmware Profile Specification\", Family \"2.0\", Level 00,\n Version 1.05, Revision 23, May 2021,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[PC-CLIENT-EFI-TPM-1.2]\n Trusted Computing Group, \"TCG EFI Platform Specification\",\n For TPM Family 1.1 or 1.2, Version 1.22, Revision 15,\n January 2014, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[PC-CLIENT-RIM]\n Trusted Computing Group, \"TCG PC Client Reference\n Integrity Manifest Specification\", Version 1.04, November\n 2020, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[PLATFORM-DEVID-TPM-2.0]\n Trusted Computing Group, \"TPM 2.0 Keys for Device Identity\n and Attestation\", Version 1.00, Revision 12, October 2021,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[PLATFORM-ID-TPM-1.2]\n Trusted Computing Group, \"TCG Infrastructure WG TPM Keys\n for Platform Identity for TPM 1.2\", Specification Version\n 1.0, Revision 3, August 2015,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC2119] Bradner, S., \"Key words for use in RFCs to Indicate\n Requirement Levels\", BCP 14, RFC 2119,\n DOI 10.17487/RFC2119, March 1997,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC4253] Ylonen, T. and C. Lonvick, Ed., \"The Secure Shell (SSH)\n Transport Layer Protocol\", RFC 4253, DOI 10.17487/RFC4253,\n January 2006, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,\n Housley, R., and W. Polk, \"Internet X.509 Public Key\n Infrastructure Certificate and Certificate Revocation List\n (CRL) Profile\", RFC 5280, DOI 10.17487/RFC5280, May 2008,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,\n and A. Bierman, Ed., \"Network Configuration Protocol\n (NETCONF)\", RFC 6241, DOI 10.17487/RFC6241, June 2011,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8174] Leiba, B., \"Ambiguity of Uppercase vs Lowercase in RFC\n 2119 Key Words\", BCP 14, RFC 8174, DOI 10.17487/RFC8174,\n May 2017, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8446] Rescorla, E., \"The Transport Layer Security (TLS) Protocol\n Version 1.3\", RFC 8446, DOI 10.17487/RFC8446, August 2018,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and\n W. Pan, \"Remote ATtestation procedureS (RATS)\n Architecture\", RFC 9334, DOI 10.17487/RFC9334, January\n 2023, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC9393] Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D.\n Waltermire, \"Concise Software Identification Tags\",\n RFC 9393, DOI 10.17487/RFC9393, June 2023,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC9684] Birkholz, H., Eckel, M., Bhandari, S., Voit, E., Sulzen,\n B., Xia, L., Laffey, T., and G. C. Fedorkow, \"A YANG Data\n Model for Challenge-Response-Based Remote Attestation\n (CHARRA) Procedures Using Trusted Platform Modules\n (TPMs)\", RFC 9684, DOI 10.17487/RFC9684, December 2024,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RIM] Trusted Computing Group, \"TCG Reference Integrity Manifest\n (RIM) Information Model\", Version 1.01, Revision 0.16,\n November 2020,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[SWID] ISO/IEC, \"Information technology - IT asset management -\n Part 2: Software identification tag\", ISO/\n IEC 19770-2:2015, October 2015,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[TAP] Trusted Computing Group, \"TCG Trusted Attestation Protocol\n (TAP) Information Model for TPM Families 1.2 and 2.0 and\n DICE Family 1.0\", Version 1.0, Revision 0.36, October\n 2018, .", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "8.2. Informative References", + "section_title": true, + "ja": "8.2. 参考引用" + }, + { + "indent": 3, + "text": "[AIK-ENROLL]\n Trusted Computing Group, \"TCG Infrastructure Working Group\n A CMC Profile for AIK Certificate Enrollment\", Version\n 1.0, Revision 7, March 2011,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[IEEE-802.1AE]\n IEEE, \"IEEE Standard for Local and metropolitan area\n networks - Media Access Control (MAC) Security\", IEEE Std \n 802.1AE-2018, DOI 10.1109/IEEESTD.2018.8585421, 2018,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[IEEE-802.1X]\n IEEE, \"IEEE Standard for Local and Metropolitan Area\n Networks - Port-Based Network Access Control\", IEEE Std \n 802.1X-2020, DOI 10.1109/IEEESTD.2020.9018454, February\n 2020, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[LLDP] IEEE, \"IEEE Standard for Local and metropolitan area\n networks - Station and Media Access Control Connectivity\n Discovery\", IEEE Std 802.1AB-2016,\n DOI 10.1109/IEEESTD.2016.7433915, March 2016,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[NET-EQ] Trusted Computing Group, \"TCG Guidance for Securing\n Network Equipment Using TCG Technology\", Version 1.0,\n Revision 29, January 2018,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[NIST-IR-8060]\n Waltermire, D., Cheikes, B. A., Feldman, L., and G. Witte,\n \"Guidelines for the Creation of Interoperable Software\n Identification (SWID) Tags\", NIST NISTIR 8060,\n DOI 10.6028/NIST.IR.8060, April 2016,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[PLATFORM-CERTS]\n Trusted Computing Group, \"TCG Platform Attribute\n Credential Profile\", Specification Version 1.0, Revision\n 16, January 2018,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[PROV-TPM-2.0]\n Trusted Computing Group, \"TCG TPM v2.0 Provisioning\n Guidance\", Version 1.0, Revision 1.0, March 2017,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RATS-EAT] Lundblade, L., Mandyam, G., O'Donoghue, J., and C.\n Wallace, \"The Entity Attestation Token (EAT)\", Work in\n Progress, Internet-Draft, draft-ietf-rats-eat-31, 6\n September 2024, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RATS-INTERACTION-MODELS]\n Birkholz, H., Eckel, M., Pan, W., and E. Voit, \"Reference\n Interaction Models for Remote Attestation Procedures\",\n Work in Progress, Internet-Draft, draft-ietf-rats-\n reference-interaction-models-11, 22 July 2024,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RATS-NET-DEV-SUB]\n Birkholz, H., Voit, E., and W. Pan, \"Attestation Event\n Stream Subscription\", Work in Progress, Internet-Draft,\n draft-ietf-rats-network-device-subscription-05, 7 July\n 2024, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RATS-TUDA]\n Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann,\n \"Time-Based Uni-Directional Attestation\", Work in\n Progress, Internet-Draft, draft-birkholz-rats-tuda-07, 10\n July 2022, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RATS-USECASES]\n Richardson, M., Wallace, C., and W. Pan, \"Use cases for\n Remote Attestation common encodings\", Work in Progress,\n Internet-Draft, draft-richardson-rats-usecases-08, 2\n November 2020, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.\n Levkowetz, Ed., \"Extensible Authentication Protocol\n (EAP)\", RFC 3748, DOI 10.17487/RFC3748, June 2004,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC6813] Salowey, J. and S. Hanna, \"The Network Endpoint Assessment\n (NEA) Asokan Attack Analysis\", RFC 6813,\n DOI 10.17487/RFC6813, December 2012,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC7950] Bjorklund, M., Ed., \"The YANG 1.1 Data Modeling Language\",\n RFC 7950, DOI 10.17487/RFC7950, August 2016,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8572] Watsen, K., Farrer, I., and M. Abrahamsson, \"Secure Zero\n Touch Provisioning (SZTP)\", RFC 8572,\n DOI 10.17487/RFC8572, April 2019,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,\n and K. Watsen, \"Bootstrapping Remote Secure Key\n Infrastructure (BRSKI)\", RFC 8995, DOI 10.17487/RFC8995,\n May 2021, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC9525] Saint-Andre, P. and R. Salz, \"Service Identity in TLS\",\n RFC 9525, DOI 10.17487/RFC9525, November 2023,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[SP800-155]\n NIST, \"BIOS Integrity Measurement Guidelines (Draft)\",\n NIST SP 800-155 (Draft), December 2011,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[SP800-193]\n NIST, \"Platform Firmware Resiliency Guidelines\", NIST\n SP 800-193, DOI 10.6028/NIST.SP.800-193, May 2018,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[SWID-GEN] Labs64, \"SoftWare IDentification (SWID) Tags Generator\n (Maven Plugin)\",\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[TCG-RT] Trusted Computing Group, \"TCG Roots of Trust\n Specification\", (Draft), Family \"1.0\", Level 00, Revision\n 0.20, July 2018, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[TPM-1.2] Trusted Computing Group, \"TPM 1.2 Main Specification\",\n Level 2, Version 1.2, Revision 116, March 2011,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[TPM-2.0] Trusted Computing Group, \"Trusted Platform Module\n Library\", Family \"2.0\", Level 00, Revision 01.83, March\n 2024, .", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "Appendix A. Supporting Materials", + "section_title": true, + "ja": "付録A. サポート材料" + }, + { + "indent": 0, + "text": "A.1. Using a TPM for Attestation", + "section_title": true, + "ja": "A.1. 証明のためにTPMを使用します" + }, + { + "indent": 3, + "text": "The TPM and surrounding ecosystem provide three interlocking capabilities to enable secure collection of evidence from a remote device: PCRs, a Quote mechanism, and a standardized Event Log.", + "ja": "TPMと周囲のエコシステムは、PCRS、引用メカニズム、標準化されたイベントログからの証拠の安全な収集を可能にする3つのインターロック機能を提供します。" + }, + { + "indent": 3, + "text": "Each TPM has at least eight and at most twenty-four PCRs (depending on the profile and vendor choices), each one large enough to hold one hash value (SHA-1, SHA-256, and other hash algorithms can be used, depending on TPM version). PCRs can't be accessed directly from outside the chip, but the TPM interface provides a way to \"extend\" a new security measurement hash into any PCR, a process by which the existing value in the PCR is hashed with the new security measurement hash, and the result placed back into the same PCR. The result is a composite fingerprint comprising the hash of all the security measurements extended into each PCR since the system was reset.", + "ja": "各TPMには、少なくとも8つ以下のPCR（プロファイルとベンダーの選択肢によって異なります）があり、それぞれが1つのハッシュ値を保持するのに十分な大きさです（SHA-1、SHA-256、およびその他のハッシュアルゴリズムは使用できます。TPMバージョンで）。PCRSにチップの外側から直接アクセスすることはできませんが、TPMインターフェイスは、新しいセキュリティ測定ハッシュをPCRに「拡張」する方法を提供します。、および結果が同じPCRに戻りました。その結果、システムがリセットされて以来、各PCRに拡張されたすべてのセキュリティ測定のハッシュを含む複合指紋が作成されます。" + }, + { + "indent": 3, + "text": "Every time a PCR is extended, an entry should be added to the corresponding Event Log. Logs contain the security measurement hash plus informative fields offering hints as to which event generated the security measurement. The Event Log itself is protected against accidental manipulation, but it is implicitly tamper-evident: Any verification process can read the security measurement hash from the log events, compute the composite value, and compare that to what is in the PCR. If there's no discrepancy, the logs do provide an accurate view of what was placed into the PCR.", + "ja": "PCRが延長されるたびに、対応するイベントログにエントリを追加する必要があります。ログには、セキュリティ測定のハッシュと、セキュリティ測定を生成するイベントに関するヒントを提供する有益なフィールドが含まれています。イベントログ自体は偶発的な操作から保護されていますが、暗黙的に改ざんされています。検証プロセスは、ログイベントからセキュリティ測定ハッシュを読み取り、コンポジット値を計算し、それをPCRのものと比較できます。矛盾がない場合、ログはPCRに配置されたものの正確なビューを提供します。" + }, + { + "indent": 3, + "text": "Note that the composite hash-of-hashes recorded in PCRs is order-dependent, resulting in different PCR values for different ordering of the same set of events (e.g., Event A followed by Event B yields a different PCR value than B followed by A). For single-threaded code, where both the events and their order are fixed, a Verifier may validate a single PCR value, and use the log only to diagnose a mismatch from Reference Values. However, operating system code is usually nondeterministic, meaning that there may never be a single \"known good\" PCR value. In this case, the Verifier may have to verify that the log is correct, and then analyze each item in the log to determine if it represents an authorized event.", + "ja": "PCRSで記録された複合ハッシュオブハッシュは順序依存性であり、同じ一連のイベントの異なる順序付けに対して異なるPCR値をもたらすことに注意してください（たとえば、イベントAが続くイベントBは、Bとは異なるPCR値を生成します。）。イベントとその注文の両方が修正されている単一の読み取りコードの場合、検証者は単一のPCR値を検証し、ログを使用して参照値からの不一致を診断することができます。ただし、オペレーティングシステムコードは通常、無決定的であるため、単一の「既知の良い」PCR値がない場合があります。この場合、検証者はログが正しいことを確認し、ログ内の各アイテムを分析して、承認されたイベントを表すかどうかを判断する必要がある場合があります。" + }, + { + "indent": 3, + "text": "In a conventional TPM Attestation environment, the first measurement must be made and extended into the TPM by trusted device code (called the RTM). That first measurement should cover the segment of code that is run immediately after the RTM, which then measures the next code segment before running it, and so on, forming an unbroken chain of trust. See [TCG-RT] for more on Mutable vs. Immutable Roots of Trust.", + "ja": "従来のTPM証明環境では、信頼できるデバイスコード（RTMと呼ばれる）により、最初の測定を行い、TPMに拡張する必要があります。その最初の測定では、RTMの直後に実行されるコードのセグメントをカバーします。これは、実行する前に次のコードセグメントを測定し、壊れていない信頼のチェーンを形成します。可変性と不変の信頼の根の詳細については、[TCG-RT]を参照してください。" + }, + { + "indent": 3, + "text": "The TPM provides another mechanism called a Quote that can read the current value of the PCRs and package them, along with the Verifier's nonce, into a TPM-specific data structure signed by an Attestation private key, known only to the TPM.", + "ja": "TPMは、PCRSの現在の値を読み取り、検証者のNonCeとともに、TPMのみで知られている証明の秘密鍵によって署名されたTPM固有のデータ構造にパッケージ化できる引用と呼ばれる別のメカニズムを提供します。" + }, + { + "indent": 3, + "text": "It's important to note that the Quote data structure is signed inside the TPM (see Section 5, Security Considerations). The trust model is preserved by retrieving the Quote in a way that does not invalidate the signature, as specified in [RFC9684]. The structure of the command and response for a quote, including its signature, as generated by the TPM, can be seen in Part 3, Section 16.5, of [TPM-1.2] and Section 18.4.2 of [TPM-2.0].", + "ja": "引用データ構造はTPM内で署名されていることに注意することが重要です（セクション5、セキュリティに関する考慮事項を参照）。信頼モデルは、[RFC9684]で指定されているように、署名を無効にしない方法で引用を取得することにより保存されます。TPMによって生成された署名を含む引用のコマンドの構造と応答は、[TPM-1.2]のパート3、セクション16.5、および[TPM-2.0]のセクション18.4.2で見ることができます。" + }, + { + "indent": 3, + "text": "The Verifier uses the Quote and Log together. The Quote contains the composite hash of the complete sequence of security measurement hashes, signed by the TPM's private AK. The Log contains a record of each measurement extended into the TPM's PCRs. By computing the composite hash of all the measurements, the Verifier can verify the integrity of the Event Log, even though the Event Log itself is not signed. Each hash in the validated Event Log can then be compared to corresponding expected values in the set of Reference Values to validate overall system integrity.", + "ja": "検証器は、引用とログを一緒に使用します。引用には、TPMのプライベートAKが署名したセキュリティ測定ハッシュの完全なシーケンスの複合ハッシュが含まれています。ログには、TPMのPCRSに拡張された各測定の記録が含まれています。すべての測定値の複合ハッシュを計算することにより、イベントログ自体が署名されていない場合でも、検証者はイベントログの整合性を検証できます。検証されたイベントログの各ハッシュは、参照値のセットの対応する期待値と比較して、システム全体の整合性を検証できます。" + }, + { + "indent": 3, + "text": "A summary of information exchanged in obtaining quotes from TPM 1.2 and TPM 2.0 can be found in [TAP], Section 4. Detailed information about PCRs and Quote data structures can be found in [TPM-1.2], [TPM-2.0]. Recommended log formats include [PC-CLIENT-BIOS-TPM-2.0], and [CEL].", + "ja": "TPM 1.2およびTPM 2.0から引用符を取得する際に交換される情報の要約は、[TAP]、セクション4にあります。PCRSおよび引用データ構造の詳細情報は、[TPM-1.2]、[TPM-2.0]にあります。推奨されるログ形式には、[PC-Client-BIOS-TPM-2.0]および[CEL]が含まれます。" + }, + { + "indent": 0, + "text": "A.2. Root of Trust for Measurement (RTM)", + "section_title": true, + "ja": "A.2. 測定のための信頼のルート（RTM）" + }, + { + "indent": 3, + "text": "The measurements needed for attestation require that the device being attested is equipped with an RTM, that is, some trustworthy mechanism that can compute the first measurement in the chain of trust required to attest that each stage of system startup is verified, a Root of Trust for Storage (i.e., the TPM PCRs) to record the results, and a Root of Trust for Reporting to report the results.", + "ja": "証明に必要な測定では、証明されているデバイスにRTM、つまり、システムスタートアップの各段階が検証されていることを証明するために必要な信頼チェーンで最初の測定値を計算できる信頼できるメカニズムが装備されていることが必要です。ストレージ（つまり、TPM PCRS）の場合、結果を記録し、結果を報告する報告のための信頼の根が記録されます。" + }, + { + "indent": 3, + "text": "While there are many complex aspects of Roots of Trust ([TCG-RT] [SP800-155] [SP800-193]), two aspects that are important in the case of attestation are:", + "ja": "信頼のルーツには多くの複雑な側面がありますが（[TCG-RT] [SP800-155] [SP800-193]）、証明の場合に重要な2つの側面は次のとおりです。" + }, + { + "indent": 6, + "text": "* The first measurement computed by the RTM and stored in the TPM's Root of Trust for Storage must be assumed to be correct.", + "ja": "* RTMによって計算され、TPMのストレージの信頼ルートに保存された最初の測定は、正しいと想定する必要があります。" + }, + { + "indent": 6, + "text": "* There must not be a way to reset the Root of Trust for Storage without re-entering the RTM code.", + "ja": "* RTMコードに再び入ることなく、ストレージのために信頼のルートをリセットする方法があってはなりません。" + }, + { + "indent": 3, + "text": "The first measurement must be computed by code that is implicitly trusted; if that first measurement can be subverted, none of the remaining measurements can be trusted. (See [SP800-155].)", + "ja": "最初の測定は、暗黙的に信頼されるコードによって計算する必要があります。その最初の測定が破壊される可能性がある場合、残りの測定値はどれも信頼できません。（[SP800-155]を参照してください。）" + }, + { + "indent": 3, + "text": "It's important to note that the trustworthiness of the RTM code cannot be assured by the TPM or TPM supplier -- code or procedures external to the TPM must guarantee the security of the RTM.", + "ja": "RTMコードの信頼性はTPMまたはTPMサプライヤーによって保証されないことに注意することが重要です。TPMの外部のコードまたは手順は、RTMのセキュリティを保証する必要があります。" + }, + { + "indent": 0, + "text": "A.3. Layering Model for Network Equipment Attester and Verifier", + "section_title": true, + "ja": "A.3. ネットワーク機器の階層モデルは、攻撃と検証装置を階層化します" + }, + { + "indent": 3, + "text": "Retrieval of identity and attestation state uses one protocol stack, while retrieval of Reference Values uses a different set of protocols. Figure 5 shows the components involved.", + "ja": "IDと証明状態の検索は1つのプロトコルスタックを使用し、参照値の取得は異なるプロトコルセットを使用します。図5は、関係するコンポーネントを示しています。" + }, + { + "indent": 3, + "text": "+-----------------------+ +-------------------------+\n| | | |\n| Attester |<-------------| Verifier |\n| (Device) |------------->| (Management Station) |\n| | | | |\n+-----------------------+ | +-------------------------+\n |\n -------------------- --------------------\n | |\n------------------------------- ---------------------------------\n| Reference Values | | Attestation |\n------------------------------- ---------------------------------\n\n********************************************************************\n* IETF Remote Attestation Conceptual Data Flow *\n* RFC9334, Figure 1 *\n********************************************************************\n\n ......................... .........................\n . Reference Integrity . . TAP Info .\n . Manifest . . Model and Canonical .\n . . . Log Format .\n ......................... .........................\n\n ************************* *************************\n * YANG SWID Module * * YANG Attestation *\n * RFC9393 * * Module *\n * * * RFC9684 *\n * * * *\n ************************* *************************\n\n ************************* *************************\n * XML, JSON, CBOR, etc. * * XML, JSON, CBOR, etc. *\n ************************* *************************\n\n ************************* *************************\n * RESTCONF/NETCONF * * RESTCONF/NETCONF *\n ************************* *************************\n\n ************************* *************************\n * TLS, SSH * * TLS, SSH *\n ************************* *************************", + "raw": true, + "ja": "" + }, + { + "indent": 23, + "text": "Figure 5: RIV Protocol Stacks", + "ja": "図5：RIVプロトコルスタック" + }, + { + "indent": 3, + "text": "IETF documents are captured in boxes surrounded by asterisks. TCG documents are shown in boxes surrounded by dots.", + "ja": "IETFドキュメントは、アスタリスクに囲まれたボックスでキャプチャされます。TCGドキュメントは、ドットに囲まれたボックスに表示されます。" + }, + { + "indent": 0, + "text": "A.4. Implementation Notes", + "section_title": true, + "ja": "A.4. 実装ノート" + }, + { + "indent": 3, + "text": "Table 2 summarizes many of the actions needed to complete an Attestation system, with links to relevant documents. While documents are controlled by several standards organizations, the implied actions required for implementation are all the responsibility of the manufacturer of the device, unless otherwise noted.", + "ja": "表2は、関連するドキュメントへのリンクを使用して、証明システムを完了するために必要なアクションの多くをまとめたものです。文書はいくつかの標準組織によって管理されていますが、特に明記しない限り、実装に必要な黙示的な行動はすべて、デバイスの製造業者の責任です。" + }, + { + "indent": 3, + "text": "As noted, SWID tags can be generated many ways, but one possible tool is [SWID-GEN].", + "ja": "前述のように、SWIDタグは多くの方法で生成できますが、可能なツールの1つは[Swid-Gen]です。" + }, + { + "indent": 3, + "text": "+========================================+==========================+\n| Component | Controlling |\n| | Specification |\n+========================================+==========================+\n| Make a Secure execution environment: | [TCG-RT] |\n| | |\n| * Attestation depends on a secure | |\n| RTM outside the TPM, as well as | |\n| Roots for Storage and Reporting | |\n| inside the TPM. | |\n| | |\n| * Refer to \"TCG Roots of Trust | |\n| Specification\" [TCG-RT]. | |\n| | |\n| * [SP800-193] also provides | |\n| guidelines on Roots of Trust. | |\n+----------------------------------------+--------------------------+\n| Provision the TPM as described in the | [PLATFORM-DEVID-TPM-2.0] |\n| TCG documents. | |\n| | [PLATFORM-CERTS] |\n+----------------------------------------+--------------------------+\n| Put a DevID or Platform Certificate | [PLATFORM-DEVID-TPM-2.0] |\n| in the TPM: | |\n| | [PLATFORM-CERTS] |\n| * Install an IAK at the same time so | |\n| that Attestation can work out of | |\n| the box. | |\n| | |\n| * Equipment suppliers and owners may | |\n| want to implement LDevID as well | |\n| as IDevID. | |\n| +--------------------------+\n| | [IEEE-802-1AR] |\n+----------------------------------------+--------------------------+\n| Connect the TPM to the TLS stack: | Vendor TLS stack (This |\n| | action configures TLS to |\n| * Use the DevID in the TPM to | use the DevID as its |\n| authenticate TAP connections, | client certificate.) |\n| identifying the device. | |\n+----------------------------------------+--------------------------+\n| Make CoSWID tags for BIOS/Loader/ | [RFC9393] |\n| Kernel objects: | |\n| | [SWID] |\n| * Add reference measurements into | |\n| SWID tags. | [NIST-IR-8060] |\n| | |\n| * Manufacturer should sign the SWID | |\n| tags. | |\n| | |\n| * The TCG RIM-IM [RIM] identifies | |\n| further procedures to create | |\n| signed RIM documents that provide | |\n| the necessary reference | |\n| information. | |\n+----------------------------------------+--------------------------+\n| Package the SWID tags with a vendor | Retrieve tags with |\n| software release: | [RFC9393]. |\n| | |\n| * A tag-generator plugin such as | |\n| [SWID-GEN] can be used. | |\n| +--------------------------+\n| | [PC-CLIENT-RIM] |\n+----------------------------------------+--------------------------+\n| Use PC Client measurement definitions | [PC-CLIENT-BIOS-TPM-2.0] |\n| to define the use of PCRs (although | |\n| Windows OS is rare on Networking | |\n| Equipment, UEFI BIOS is not). | |\n+----------------------------------------+--------------------------+\n| Use TAP to retrieve measurements: | [RFC9684] |\n| | |\n| * Map to YANG. | [CEL] |\n| | |\n| * Use Canonical Log Format. | |\n+----------------------------------------+--------------------------+\n| A Verifier (as described in | |\n| [RFC9334], Section 3) should request | |\n| the attestation and analyze the | |\n| result. The Verifier application | |\n| might be broken down to several more | |\n| components: | |\n| | |\n| * A Posture Manager Server that | |\n| collects reports and stores them | |\n| in a database. | |\n| | |\n| * One or more Analyzers that can | |\n| look at the results and figure out | |\n| what it means. | |\n+----------------------------------------+--------------------------+", + "raw": true, + "ja": "" + }, + { + "indent": 25, + "text": "Table 2: Component Status", + "ja": "表2：コンポーネントステータス" + }, + { + "indent": 0, + "text": "Acknowledgements", + "section_title": true, + "ja": "謝辞" + }, + { + "indent": 3, + "text": "The authors wish to thank numerous reviewers for generous assistance, including William Bellingrath, Mark Baushke, Ned Smith, Henk Birkholz, Tom Laffey, Dave Thaler, Wei Pan, Michael Eckel, Thomas Hardjono, Bill Sulzen, Willard (Monty) Wiseman, Kathleen Moriarty, Nancy Cam-Winget, and Shwetha Bhandari.", + "ja": "著者は、ウィリアム・ベリングラス、マーク・バウシュケ、ネッド・スミス、ヘンク・バークホルツ、トム・ラフィー、デイブ・ターラー、ウェイ・パン、マイケル・エッケル、トーマス・ハードジョノ、ビル・スルゼン、ウィラード（モンティ）ワイズマン、カトリーン・モリルティアティルティアン・モリエン・モリアルティアの寛大な支援について、多数のレビュアーに感謝したいと考えています。、ナンシー・カム・ウィンゲット、シュエサ・バンダリ。" + }, + { + "indent": 0, + "text": "Authors' Addresses", + "section_title": true, + "ja": "著者のアドレス" + }, + { + "indent": 3, + "text": "Guy C. Fedorkow (editor)\nJuniper Networks, Inc.\n10 Technology Park Drive\nWestford, Massachusetts 01886\nUnited States of America\nEmail: gfedorkow@juniper.net", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Eric Voit\nCisco Systems\nEmail: evoit@cisco.com", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Jessica Fitzgerald-McKay\nNational Security Agency\n9800 Savage Road\nFt. Meade, Maryland 20755\nUnited States of America\nEmail: jmfitz2@nsa.gov", + "raw": true, + "ja": "" + } + ] +} \ No newline at end of file diff --git a/data/9000/rfc9684-trans.json b/data/9000/rfc9684-trans.json new file mode 100644 index 000000000..121c8b092 --- /dev/null +++ b/data/9000/rfc9684-trans.json @@ -0,0 +1,1156 @@ +{ + "title": { + "text": "RFC 9684 - A YANG Data Model for Challenge-Response-Based Remote Attestation (CHARRA) Procedures Using Trusted Platform Modules (TPMs)", + "ja": "RFC 9684 - 信頼できるプラットフォームモジュール（TPM）を使用したチャレンジ応答ベースのリモート証明（Charra）手順のYangデータモデル" + }, + "number": 9684, + "created_at": "2024-12-09 23:24:06.219985+09:00", + "updated_by": "", + "contents": [ + { + "indent": 0, + "text": "Internet Engineering Task Force (IETF) H. Birkholz\nRequest for Comments: 9684 M. Eckel\nCategory: Standards Track Fraunhofer SIT | ATHENE\nISSN: 2070-1721 S. Bhandari\n ThoughtSpot\n E. Voit\n B. Sulzen\n Cisco\n L. Xia\n Huawei\n T. Laffey\n HPE\n G. C. Fedorkow\n Juniper\n December 2024", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "A YANG Data Model for Challenge-Response-Based Remote Attestation (CHARRA) Procedures Using Trusted Platform Modules (TPMs)", + "section_title": true, + "ja": "信頼できるプラットフォームモジュール（TPM）を使用したチャレンジ応答ベースのリモート証明（Charra）手順のYangデータモデル" + }, + { + "indent": 0, + "text": "Abstract", + "section_title": true, + "ja": "概要" + }, + { + "indent": 3, + "text": "This document defines the YANG Remote Procedure Calls (RPCs) and configuration nodes that are required to retrieve attestation evidence about integrity measurements from a device, following the operational context defined in RFC 9683 \"TPM-based Network Device Remote Integrity Verification\". Complementary measurement logs originating from one or more Roots of Trust for Measurement (RTMs) are also provided by the YANG RPCs. The defined module requires the inclusion of the following in the device components of the composite device on which the YANG server is running: at least one Trusted Platform Module (TPM) of either version 1.2 or 2.0 as well as a corresponding TPM Software Stack (TSS), or an equivalent hardware implementation that includes the protected capabilities as provided by TPMs as well as a corresponding software stack.", + "ja": "このドキュメントでは、RFC 9683「TPMベースのネットワークデバイスリモートインテグリティ検証」で定義されている運用コンテキストに従って、デバイスからの整合性測定に関する証明の証拠を取得するために必要なYangリモートプロシージャコール（RPC）と構成ノードを定義します。測定のための1つ以上の信頼のルート（RTMS）に由来する補完測定ログも、Yang RPCによって提供されます。定義されたモジュールでは、Yangサーバーが実行されている複合デバイスのデバイスコンポーネントに次のものを含める必要があります。バージョン1.2または2.0のいずれかの少なくとも1つの信頼できるプラットフォームモジュール（TPM）と対応するTPMソフトウェアスタック（TSS）、またはTPMSと対応するソフトウェアスタックによって提供される保護された機能を含む同等のハードウェア実装。" + }, + { + "indent": 0, + "text": "Status of This Memo", + "section_title": true, + "ja": "本文書の位置付け" + }, + { + "indent": 3, + "text": "This is an Internet Standards Track document.", + "ja": "これは、インターネット標準トラックドキュメントです。" + }, + { + "indent": 3, + "text": "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.", + "ja": "このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。" + }, + { + "indent": 3, + "text": "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/rfc9684.", + "ja": "このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9684で取得できます。" + }, + { + "indent": 0, + "text": "Copyright Notice", + "section_title": true, + "ja": "著作権表示" + }, + { + "indent": 3, + "text": "Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.", + "ja": "著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。" + }, + { + "indent": 3, + "text": "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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.", + "ja": "このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。" + }, + { + "indent": 0, + "text": "Table of Contents", + "section_title": true, + "ja": "目次" + }, + { + "indent": 3, + "text": "1. Introduction\n 1.1. Requirements Notation\n2. The YANG Module for Basic Remote Attestation Procedures\n 2.1. YANG Modules\n 2.1.1. ietf-tpm-remote-attestation\n 2.1.2. ietf-tcg-algs\n3. IANA Considerations\n4. Security Considerations\n5. References\n 5.1. Normative References\n 5.2. Informative References\nAppendix A. Integrity Measurement Architecture (IMA)\nAppendix B. IMA for Network Equipment Boot Logs\nAuthors' Addresses", + "raw": true, + "toc": true, + "ja": "" + }, + { + "indent": 0, + "text": "1. Introduction", + "section_title": true, + "ja": "1. はじめに" + }, + { + "indent": 3, + "text": "This document is based on the general terminology defined in Remote ATtestation procedureS (RATS) architecture [RFC9334] and uses the operational context defined in [RFC9683] as well as the interaction model and information elements defined in [RATS-Interaction-Models]. The currently supported hardware security modules (HSMs) are the Trusted Platform Modules (TPMs) [TPM1.2] [TPM2.0] as specified by the Trusted Computing Group (TCG). One TPM, or multiple TPMs in the case of a composite device, is required in order to use the YANG module defined in this document. Each TPM is used as a Root of Trust for Storage (RTS) in order to store system security measurement Evidence. And each TPM is used as a Root of Trust for Reporting (RTR) in order to retrieve attestation Evidence. This is done by using a YANG RPC to request a quote that exposes a rolling hash of the security measurements held internally within the TPM.", + "ja": "このドキュメントは、リモート認証手順（RAT）アーキテクチャ[RFC9334]で定義されている一般的な用語に基づいており、[RFC9683]で定義されている運用コンテキストと、[RATS-Interaction-Models]で定義された相互作用モデルと情報要素を使用します。現在サポートされているハードウェアセキュリティモジュール（HSM）は、信頼できるコンピューティンググループ（TCG）で指定されている信頼できるプラットフォームモジュール（TPMS）[TPM1.2] [TPM2.0]です。このドキュメントで定義されているYangモジュールを使用するには、複合デバイスの場合の1つのTPM、または複数のTPMが必要です。各TPMは、システムセキュリティ測定の証拠を保存するために、ストレージ（RTS）の信頼のルートとして使用されます。また、各TPMは、証拠の証拠を取得するために、レポート（RTR）の信頼のルートとして使用されます。これは、Yang RPCを使用して、TPM内で内部に保持されているセキュリティ測定値のローリングハッシュを公開する引用をリクエストすることによって行われます。" + }, + { + "indent": 3, + "text": "Specific terms imported from [RFC9334] and used in this document include Attester, composite device, and Evidence.", + "ja": "[RFC9334]からインポートされ、このドキュメントで使用されている特定の用語には、Attester、複合装置、および証拠が含まれます。" + }, + { + "indent": 3, + "text": "Specific terms imported from [TPM2.0-Key] and used in this document include Endorsement Key (EK), Initial Attestation Key (IAK), Attestation Identity Key (AIK), and Local Attestation Key (LAK).", + "ja": "[TPM2.0-KEY]からインポートされ、このドキュメントで使用されている特定の用語には、承認キー（EK）、初期証明キー（IAK）、証明IDキー（AIK）、およびローカル証明キー（LAK）が含まれます。" + }, + { + "indent": 0, + "text": "1.1. Requirements Notation", + "section_title": true, + "ja": "1.1. 要件表記" + }, + { + "indent": 3, + "text": "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.", + "ja": "「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 \"not\"、 \"becommended\"、 \"becommented\"、 \"may\"、 \"optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。" + }, + { + "indent": 0, + "text": "2. The YANG Module for Basic Remote Attestation Procedures", + "section_title": true, + "ja": "2. 基本的なリモート証明手順のためのYangモジュール" + }, + { + "indent": 3, + "text": "One or more TPMs MUST be embedded in a composite device that provides attestation Evidence via the YANG module defined in this document. The ietf-tpm-remote-attestation YANG module enables a composite device to take on the role of an Attester, in accordance with the RATS architecture [RFC9334] and the corresponding challenge-response interaction model defined in [RATS-Interaction-Models]. A fresh nonce with an appropriate amount of entropy [NIST-915121] MUST be supplied by the YANG client in order to enable a proof-of-freshness with respect to the attestation Evidence provided by the Attester running the YANG datastore. Further, this nonce is used to prevent replay attacks. The method for communicating the relationship of each individual TPM to the specific measured component within the composite device is out of the scope of this document.", + "ja": "このドキュメントで定義されているYangモジュールを介して証明の証拠を提供する複合デバイスに1つ以上のTPMを埋め込む必要があります。IETF-TPM-Remote-Attestation Yangモジュールは、[RFC9334]および[RATS-Interaction-Models]で定義された対応する課題と課題との対応相互作用モデルに従って、複合デバイスが攻撃者の役割を引き受けることを可能にします。適切な量のエントロピー[NIST-915121]を備えた新鮮な非CEは、Yangデータストアを実行しているAttesterが提供する証明の証拠に関して新鮮な証明を可能にするために、Yangクライアントから提供する必要があります。さらに、このノンセは、リプレイ攻撃を防ぐために使用されます。個々のTPMの関係を複合デバイス内の特定の測定コンポーネントと通信する方法は、このドキュメントの範囲外です。" + }, + { + "indent": 0, + "text": "2.1. YANG Modules", + "section_title": true, + "ja": "2.1. ヤンモジュール" + }, + { + "indent": 3, + "text": "In this section, the two YANG modules are defined.", + "ja": "このセクションでは、2つのYangモジュールが定義されています。" + }, + { + "indent": 0, + "text": "2.1.1. ietf-tpm-remote-attestation", + "section_title": true, + "ja": "2.1.1. IETF-TPM-Remote-Attestation" + }, + { + "indent": 3, + "text": "This YANG module imports modules from [RFC6991] with prefix 'yang', [RFC8348] with prefix 'hw', [RFC9642] with prefix 'ks', and ietf-tcg-algs.yang Section 2.1.2.3 with prefix 'taa'. Additionally, references are made to [RFC6933], [TPM1.2-Commands], [TPM2.0-Arch], [TPM2.0-Structures], [TPM2.0-Key], [TPM1.2-Structures], [BIOS-Log], and [CEL], as well as Appendix B.", + "ja": "このYangモジュールは、[RFC6991]からモジュールをプレフィックス「YANG」、[RFC8348]、プレフィックス「HW」、[RFC9642]をプレフィックス「KS」、IETF-TCG-ALGS.YANGセクション2.1.2.3でプレフィックス「TAA」とともにインポートします。。さらに、参照は[RFC6933]、[TPM1.2-Commands]、[TPM2.0-Arch]、[TPM2.0-fructures]、[TPM2.0-KEY]、[TPM1.2-structures]、[TPM2.0-Key]、[TPM2.0-KEY]、[TPM2.0-KEY]、[bios-log]、および[cel]、および付録B" + }, + { + "indent": 0, + "text": "2.1.1.1. Features", + "section_title": true, + "ja": "2.1.1.1. 特徴" + }, + { + "indent": 3, + "text": "This module supports the following features:", + "ja": "このモジュールは、次の機能をサポートしています。" + }, + { + "indent": 3, + "text": "'mtpm':", + "ja": "「mtpm」：" + }, + { + "indent": 12, + "text": "Indicates that multiple TPMs on the device can support remote attestation. For example, this feature could be used in cases where multiple line cards are present, each with its own TPM.", + "ja": "デバイス上の複数のTPMがリモートの証明をサポートできることを示します。たとえば、この機能は、複数のラインカードが存在する場合に使用でき、それぞれ独自のTPMがあります。" + }, + { + "indent": 3, + "text": "'bios':", + "ja": "「bios」：" + }, + { + "indent": 12, + "text": "Indicates that the device supports the retrieval of BIOS and Unified Extensible Firmware Interface (UEFI) event logs [BIOS-Log].", + "ja": "デバイスは、BIOSおよび統合された拡張可能なファームウェアインターフェイス（UEFI）イベントログ[BIOS-LOG]の検索をサポートしていることを示します。" + }, + { + "indent": 3, + "text": "'ima':", + "ja": "「イマ」：" + }, + { + "indent": 12, + "text": "Indicates that the device supports the retrieval of event logs from the Linux Integrity Measurement Architecture (IMA, see Appendix A).", + "ja": "このデバイスは、Linux Integrity測定アーキテクチャからのイベントログの取得をサポートしていることを示します（IMA、付録Aを参照）。" + }, + { + "indent": 3, + "text": "'netequip_boot':", + "ja": "'net quip_boot'：" + }, + { + "indent": 12, + "text": "Indicates that the device supports the retrieval of netequip boot event logs. See Appendixes A and B.", + "ja": "デバイスがNet Quip Bootイベントログの取得をサポートしていることを示します。付録AとBを参照してください。" + }, + { + "indent": 0, + "text": "2.1.1.2. Identities", + "section_title": true, + "ja": "2.1.1.2. アイデンティティ" + }, + { + "indent": 3, + "text": "This module supports the following types of attestation event logs: 'bios', 'ima', and 'netequip_boot'.", + "ja": "このモジュールは、「BIOS」、「IMA」、および「net quip_boot」の証明イベントログの次の種類をサポートしています。" + }, + { + "indent": 0, + "text": "2.1.1.3. Remote Procedure Calls (RPCs)", + "section_title": true, + "ja": "2.1.1.3. リモートプロシージャコール（RPC）" + }, + { + "indent": 3, + "text": "In the following sections, RPCs for attestation procedures for both TPM 1.2 and TPM 2.0 are defined.", + "ja": "次のセクションでは、TPM 1.2とTPM 2.0の両方の証明手順のRPCが定義されています。" + }, + { + "indent": 0, + "text": "2.1.1.3.1. tpm12-challenge-response-attestation", + "section_title": true, + "ja": "2.1.1.3.1. TPM12-Challenge-Response-Attestation" + }, + { + "indent": 3, + "text": "This RPC allows a Verifier to request via the _TPM Quote_ operation, signed TPM Platform Configuration Registers (PCRs) from a cryptoprocessor compliant with TPM 1.2. Where the feature 'mtpm' is active, and one or more 'certificate-name' is not provided, all cryptoprocessors compliant with TPM 1.2 will respond. The YANG tree diagram of this RPC is as follows:", + "ja": "このRPCにより、検証者は_TPM QUOTE_操作を介して要求できます。TPM1.2に準拠した暗号化プロセッサからTPMプラットフォーム構成レジスタ（PCR）に署名されます。機能「mtpm」がアクティブであり、1つ以上の「証明書名」が提供されていない場合、すべての暗号プロセッサがTPM 1.2に準拠しています。このRPCのヤンツリー図は次のとおりです。" + }, + { + "indent": 3, + "text": "+---x tpm12-challenge-response-attestation {taa:tpm12}?\n +---w input\n | +---w tpm12-attestation-challenge\n | +---w pcr-index* pcr\n | +---w nonce-value binary\n | +---w certificate-name* certificate-name-ref\n | {tpm:mtpm}?\n +--ro output\n +--ro tpm12-attestation-response* []\n +--ro certificate-name certificate-name-ref\n +--ro up-time? uint32\n +--ro TPM_QUOTE2? binary", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "2.1.1.3.2. tpm20-challenge-response-attestation", + "section_title": true, + "ja": "2.1.1.3.2. TPM20-Challenge-Response-Attestation" + }, + { + "indent": 3, + "text": "This RPC allows a Verifier to request signed TPM PCRs (_TPM Quote_ operation) from a cryptoprocessor compliant with TPM 2.0. Where the feature 'mtpm' is active, and one or more 'certificate-name' is not provided, all cryptoprocessors compliant with TPM 2.0 will respond. The YANG tree diagram of this RPC is as follows:", + "ja": "このRPCを使用すると、検証者は、TPM 2.0に準拠したクリプトプロセッサから署名されたTPM PCRS（_TPM QUOTE_操作）を要求できます。機能「mtpm」がアクティブであり、1つ以上の「証明書名」が提供されていない場合、すべての暗号プロセッサがTPM 2.0に準拠しています。このRPCのヤンツリー図は次のとおりです。" + }, + { + "indent": 3, + "text": "+---x tpm20-challenge-response-attestation {taa:tpm20}?\n +---w input\n | +---w tpm20-attestation-challenge\n | +---w nonce-value binary\n | +---w tpm20-pcr-selection* []\n | | +---w tpm20-hash-algo? identityref\n | | +---w pcr-index* pcr\n | +---w certificate-name* certificate-name-ref\n | {tpm:mtpm}?\n +--ro output\n +--ro tpm20-attestation-response* []\n +--ro certificate-name certificate-name-ref\n +--ro TPMS_QUOTE_INFO binary\n +--ro quote-signature? binary\n +--ro up-time? uint32\n +--ro unsigned-pcr-values* []\n +--ro tpm20-hash-algo? identityref\n +--ro pcr-values* [pcr-index]\n +--ro pcr-index pcr\n +--ro pcr-value? binary", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "An example of an RPC challenge requesting PCRs 0-7 from a SHA-256 bank could look like the following:", + "ja": "SHA-256銀行からPCRS 0-7を要求するRPCチャレンジの例は、次のように見えることができます。" + }, + { + "indent": 3, + "text": "\n \n \n (identifier of a TPM signature key with which the Attester is\n supposed to sign the attestation data)\n \n \n 0xe041307208d9f78f5b1bbecd19e2d152ad49de2fc5a7d8dbf769f6b8ffdeab9\n \n \n \n TPM_ALG_SHA256\n \n 0\n 1\n 2\n 3\n 4\n 5\n 6\n 7\n \n \n", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "A successful response could be formatted as follows:", + "ja": "成功した応答は、次のようにフォーマットできます。" + }, + { + "indent": 3, + "text": "\n \n \n (instance of certificate name in the keystore)\n \n \n (raw attestation data, i.e., the TPM quote; this includes,\n among other information, a composite digest of requested PCRs,\n the nonce, and TPM 2.0 clock information.)\n \n \n (signature over attestation-data using the TPM key\n identified by sig-key-id)\n \n \n", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "2.1.1.4. log-retrieval", + "section_title": true, + "ja": "2.1.1.4. log-retrieval" + }, + { + "indent": 3, + "text": "This RPC allows a Verifier to acquire the Evidence that was extended into specific TPM PCRs. The YANG tree diagram of this RPC is as follows:", + "ja": "このRPCにより、検証者は特定のTPM PCRSに拡張された証拠を取得できます。このRPCのヤンツリー図は次のとおりです。" + }, + { + "indent": 3, + "text": "+---x log-retrieval\n +---w input\n | +---w log-type identityref\n | +---w log-selector* []\n | +---w name* string\n | +---w (index-type)?\n | | +--:(last-entry)\n | | | +---w last-entry-value? binary\n | | +--:(index)\n | | | +---w last-index-number? uint64\n | | +--:(timestamp)\n | | +---w timestamp? yang:date-and-time\n | +---w log-entry-quantity? uint16\n +--ro output\n +--ro system-event-logs\n +--ro node-data* []\n +--ro name? string\n +--ro up-time? uint32\n +--ro log-result\n +--ro (attested_event_log_type)\n +--:(bios) {bios}?\n | +--ro bios-event-logs\n | +--ro bios-event-entry* [event-number]\n | +--ro event-number uint32\n | +--ro event-type? uint32\n | +--ro pcr-index? pcr\n | +--ro digest-list* []\n | | +--ro hash-algo? identityref\n | | +--ro digest* binary\n | +--ro event-size? uint32\n | +--ro event-data* binary\n +--:(ima) {ima}?\n | +--ro ima-event-logs\n | +--ro ima-event-entry* [event-number]\n | +--ro event-number uint64\n | +--ro ima-template? string\n | +--ro filename-hint? string\n | +--ro filedata-hash? binary\n | +--ro filedata-hash-algorithm? string\n | +--ro template-hash-algorithm? string\n | +--ro template-hash? binary\n | +--ro pcr-index? pcr\n | +--ro signature? binary\n +--:(netequip_boot) {netequip_boot}?\n +--ro boot-event-logs\n +--ro boot-event-entry* [event-number]\n +--ro event-number uint64\n +--ro ima-template? string\n +--ro filename-hint? string\n +--ro filedata-hash? binary\n +--ro filedata-hash-algorithm? string\n +--ro template-hash-algorithm? string\n +--ro template-hash? binary\n +--ro pcr-index? pcr\n +--ro signature? binary", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "2.1.1.5. Data Nodes", + "section_title": true, + "ja": "2.1.1.5. データノード" + }, + { + "indent": 3, + "text": "This section provides a high-level description of the data nodes that contain the configuration and operational objects within the YANG data model. For more details, please see the YANG module itself in Figure 1.", + "ja": "このセクションでは、Yangデータモデル内の構成と動作オブジェクトを含むデータノードの高レベルの説明を提供します。詳細については、図1のYangモジュール自体を参照してください。" + }, + { + "indent": 3, + "text": "Container 'rats-support-structures':", + "ja": "コンテナ「ラット - サポート構造」：" + }, + { + "indent": 12, + "text": "This houses the set of information relating to remote attestation for a device. This includes specific device TPM(s), the compute nodes (such as line cards) on which the TPM(s) reside, and the algorithms supported across the platform.", + "ja": "これにより、デバイスのリモート認証に関する情報のセットがあります。これには、特定のデバイスTPM、TPM（S）が存在するコンピューティングノード（ラインカードなど）、およびプラットフォーム全体でサポートされるアルゴリズムが含まれます。" + }, + { + "indent": 3, + "text": "Container 'tpms':", + "ja": "コンテナ 'tpms'：" + }, + { + "indent": 12, + "text": "This provides configuration and operational details for each supported TPM, including the tpm-firmware-version, PCRs that may be quoted, certificates that are associated with that TPM, and the current operational status. Of note are the certificates that are associated with that TPM. As a certificate is associated with a particular TPM Attestation Key, knowledge of the certificate allows a specific TPM to be identified.", + "ja": "これにより、TPM-Firmware-version、引用できるPCR、そのTPMに関連付けられている証明書、現在の運用ステータスなど、サポートされている各TPMの構成と運用の詳細が提供されます。注目すべきは、そのTPMに関連付けられている証明書です。証明書は特定のTPM証明キーに関連付けられているため、証明書の知識により、特定のTPMを特定できます。" + }, + { + "indent": 3, + "text": "+--rw tpms\n +--rw tpm* [name]\n +--rw name string\n +--ro hardware-based boolean\n +--ro physical-index? int32 {hw:entity-mib}?\n +--ro path? string\n +--ro compute-node compute-node-ref {tpm:mtpm}?\n +--ro manufacturer? string\n +--rw firmware-version identityref\n +--rw tpm12-hash-algo? identityref {taa:tpm12}?\n +--rw tpm12-pcrs* pcr\n +--rw tpm20-pcr-bank* [tpm20-hash-algo] {taa:tpm20}?\n | +--rw tpm20-hash-algo identityref\n | +--rw pcr-index* tpm:pcr\n +--ro status enumeration\n +--rw certificates\n +--rw certificate* [name]\n +--rw name string\n +--rw keystore-ref? leafref {ks:asymmetric-keys}?\n +--rw type? enumeration", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Container 'attester-supported-algos':", + "ja": "コンテナ「Astester-Supported-Algos」：" + }, + { + "indent": 12, + "text": "This identifies which TCG hash algorithms are available for use on the Attesting platform. An operator will use this information to limit algorithms available for use by RPCs to just a desired set from the universe of all hash algorithms allowed by the TCG.", + "ja": "これは、どのTCGハッシュアルゴリズムが証明プラットフォームで使用できるかを識別します。オペレーターは、この情報を使用して、RPCが使用できるアルゴリズムを、TCGで許可されたすべてのハッシュアルゴリズムのユニバースから目的のセットに限ります。" + }, + { + "indent": 3, + "text": "+--rw attester-supported-algos\n +--rw tpm12-asymmetric-signing* identityref {taa:tpm12}?\n +--rw tpm12-hash* identityref {taa:tpm12}?\n +--rw tpm20-asymmetric-signing* identityref {taa:tpm20}?\n +--rw tpm20-hash* identityref {taa:tpm20}?", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Container 'compute-nodes':", + "ja": "コンテナ「計算ノード」：" + }, + { + "indent": 12, + "text": "When there is more than one TPM supported, this container maintains the set of information related to the compute node associated with a specific TPM. This allows each specific TPM to identify to which 'compute-node' it belongs.", + "ja": "複数のTPMがサポートされている場合、このコンテナは、特定のTPMに関連付けられた計算ノードに関連する情報セットを維持します。これにより、特定の各TPMが属する「計算ノード」を特定できるようになります。" + }, + { + "indent": 3, + "text": "+--rw compute-nodes {tpm:mtpm}?\n +--ro compute-node* [node-id]\n +--ro node-id string\n +--ro node-physical-index? int32 {hw:entity-mib}?\n +--ro node-name? string\n +--ro node-location? string", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "2.1.1.6. YANG Module", + "section_title": true, + "ja": "2.1.1.6. ヤンモジュール" + }, + { + "indent": 0, + "text": " file \"ietf-tpm-remote-attestation@2024-12-05.yang\"\nmodule ietf-tpm-remote-attestation {\n yang-version 1.1;\n namespace \"urn:ietf:params:xml:ns:yang\"\n + \":ietf-tpm-remote-attestation\";\n prefix tpm;\n\n import ietf-yang-types {\n prefix yang;\n }\n import ietf-hardware {\n prefix hw;\n }\n import ietf-keystore {\n prefix ks;\n }\n import ietf-tcg-algs {\n prefix taa;\n }\n\n organization\n \"IETF RATS (Remote ATtestation procedureS) Working Group\";\n contact\n \"WG Web : \n WG List : \n Author : Eric Voit \n Author : Henk Birkholz \n Author : Michael Eckel \n Author : Shwetha Bhandari \n Author : Bill Sulzen \n Author : Liang Xia (Frank) \n Author : Tom Laffey \n Author : Guy C. Fedorkow \";\n description\n \"A YANG module to enable remote attestation procedures based\n on TPM 1.2 and TPM 2.0 using a challenge-response\n interaction model and the Quote primitive operations defined\n by TPM 1.2 and TPM 2.0.\n\n The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL\n NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',\n 'MAY', and 'OPTIONAL' in this document are to be interpreted as\n described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,\n they appear in all capitals, as shown here.\n\n Copyright (c) 2024 IETF Trust and the persons identified as\n authors of the code. All rights reserved.\n\n Redistribution and use in source and binary forms, with or\n without modification, is permitted pursuant to, and subject to\n the license terms contained in, the Revised BSD License set\n forth in Section 4.c of the IETF Trust's Legal Provisions\n Relating to IETF Documents\n (https://trustee.ietf.org/license-info).\n\n This version of this YANG module is part of RFC 9684; see the\n RFC itself for full legal notices.\";\n\n revision 2024-12-05 {\n description\n \"Initial version\";\n reference\n \"RFC 9684: A YANG Data Model for Challenge-Response-Based\n Remote Attestation (CHARRA) Procedures Using Trusted Platform\n Modules (TPMs)\";\n }\n\n /*****************/\n /* Features */\n /*****************/\n\n feature mtpm {\n description\n \"The device supports the remote attestation of multiple\n TPM-based cryptoprocessors.\";\n }\n\n feature bios {\n description\n \"The device supports the BIOS logs.\";\n reference\n \"BIOS-Log:\n TCG PC Client Platform Firmware Profile Specification,\n https://trustedcomputinggroup.org/wp-content/uploads/\n TCG-PC-Client-Platform-Firmware-Profile-Version-1.06-\n Revision-52_pub-2.pdf, Section 10.4.5.2\";\n }\n\n feature ima {\n description\n \"The device supports Integrity Measurement Architecture logs.\n Many variants of IMA logs exist in the deployment. Each\n encodes the log entry contents as the specific measurements\n that get hashed into a PCRs as Evidence. See the reference\n below for one example of such an encoding.\";\n reference\n \"CEL:\n Canonical Event Log Format,\n https://www.trustedcomputinggroup.org/wp-content/uploads/\n TCG_IWG_CEL_v1_r0p41_pub.pdf, Section 5.1.6\";\n }\n\n feature netequip_boot {\n description\n \"The device supports the netequip_boot logs.\";\n reference\n \"RFC 9684: A YANG Data Model for Challenge-Response-Based\n Remote Attestation (CHARRA) Procedures Using Trusted Platform\n Modules (TPMs), Appendix B\";\n }\n\n /*****************/\n /* Typedefs */\n /*****************/\n\n typedef pcr {\n type uint8 {\n range \"0..31\";\n }\n description\n \"Valid index number for a PCR. A PCR index compliant with\n TPM 2.0 extends from 0-31. At this time, a typical TPM would\n have no more than 32 PCRs.\";\n }\n\n typedef compute-node-ref {\n type leafref {\n path \"/tpm:rats-support-structures/tpm:compute-nodes\"\n + \"/tpm:compute-node/tpm:node-id\";\n }\n description\n \"This type is used to reference a hardware node. Note that an\n implementer might include an alternative leafref pointing to a\n different YANG module node specifying hardware structures.\";\n }\n\n typedef certificate-name-ref {\n type leafref {\n path \"/tpm:rats-support-structures/tpm:tpms/tpm:tpm\"\n + \"/tpm:certificates/tpm:certificate/tpm:name\";\n }\n description\n \"A type that allows identification of a TPM-based\n certificate.\";\n }\n\n /******************/\n /* Identities */\n /******************/\n\n identity attested_event_log_type {\n description\n \"Base identity allowing categorization of the reasons why an\n attested measurement has been taken on an Attester.\";\n }\n\n identity ima {\n base attested_event_log_type;\n description\n \"An event type recorded in IMA.\";\n }\n\n identity bios {\n base attested_event_log_type;\n description\n \"An event type associated with BIOS/UEFI.\";\n }\n\n identity netequip_boot {\n base attested_event_log_type;\n description\n \"An event type associated with Network Equipment Boot.\";\n }\n\n /*****************/\n /* Groupings */\n /*****************/\n\n grouping tpm20-hash-algo {\n description\n \"The cryptographic algorithm used to hash the PCRs compliant\n with TPM 2.0. This must be from the list of platform-\n supported options.\";\n leaf tpm20-hash-algo {\n type identityref {\n base taa:hash;\n }\n must '. = /tpm:rats-support-structures'\n + '/tpm:attester-supported-algos/tpm:tpm20-hash' {\n error-message \"This platform does not support \"\n + \"tpm20-hash-algo\";\n }\n description\n \"The hash scheme that is used to hash a PCR compliant with\n TPM 2.0. This must be one of those supported by a platform.\n Where this object does not appear, the default value of\n 'taa:TPM_ALG_SHA256' will apply.\";\n }\n }\n\n grouping tpm12-hash-algo {\n description\n \"The cryptographic algorithm used to hash the PCRs compliant\n with TPM 1.2.\";\n leaf tpm12-hash-algo {\n type identityref {\n base taa:hash;\n }\n must '. = /tpm:rats-support-structures'\n + '/tpm:attester-supported-algos/tpm:tpm12-hash' {\n error-message \"This platform does not support \"\n + \"tpm12-hash-algo\";\n }\n description\n \"The hash scheme that is used to hash a PCR compliant with\n TPM 1.2. This MUST be one of those supported by a platform.\n Where this object does not appear, the default value of\n 'taa:TPM_ALG_SHA1' will apply.\";\n }\n }\n\n grouping nonce {\n description\n \"A random number intended to guarantee freshness and for use\n as part of a replay-detection mechanism.\";\n leaf nonce-value {\n type binary;\n mandatory true;\n description\n \"A cryptographically generated random number that should\n not be predictable prior to its issuance from a random\n number generation function. The random number MUST be\n derived from an entropy source external to the Attester.\n\n Note that a nonce sent into a TPM will typically be 160 or\n 256 binary digits long. (This is 20 or 32 bytes.) So if\n fewer binary digits are sent, this nonce object will be\n padded with leading zeros within Quotes returned from the\n TPM. Additionally, if more bytes are sent, the nonce will\n be trimmed to the most significant binary digits.\";\n }\n }\n\n grouping tpm12-pcr-selection {\n description\n \"A Verifier can request one or more PCR values using its\n individually created Attestation Key Certificate (AC).\n The corresponding selection filter is represented in this\n grouping.\";\n leaf-list pcr-index {\n type pcr;\n description\n \"The numbers/indexes of the PCRs. In addition, any selection\n of PCRs MUST verify that the set of PCRs requested are a\n subset of the set of PCRs exposed in the leaf-list\n /tpm:rats-support-structures\n /tpm:tpms/tpm:tpm[name=current()]/tpm:tpm12-pcrs\";\n }\n }\n\n grouping tpm20-pcr-selection {\n description\n \"A Verifier can acquire one or more PCR values, which are\n hashed together in a TPM2B_DIGEST coming from the TPM2.\n The selection list of desired PCRs and the hash algorithm\n is represented in this grouping.\";\n list tpm20-pcr-selection {\n unique \"tpm20-hash-algo\";\n description\n \"Specifies the list of PCRs and hash algorithms that can be\n returned within a TPM2B_DIGEST.\";\n reference\n \"TPM2.0-Structures:\n Trusted Platform Module Library Part 2: Structures,\n Revision 01.83, https://trustedcomputinggroup.org/\n wp-content/uploads/TPM-2.0-1.83-Part-2-Structures.pdf,\n Section 10.9.7\";\n uses tpm20-hash-algo;\n leaf-list pcr-index {\n type pcr;\n description\n \"The numbers of the PCRs that are being tracked\n with a hash based on the tpm20-hash-algo. In addition,\n any selection of PCRs MUST verify that the set of PCRs\n requested are a subset of the set of selected PCR indexes\n available for that specific TPM.\";\n }\n }\n }\n\n grouping certificate-name-ref {\n description\n \"Identifies a certificate in a keystore.\";\n leaf certificate-name {\n type certificate-name-ref;\n mandatory true;\n description\n \"Identifies a certificate in a keystore.\";\n }\n }\n\n grouping tpm-name {\n description\n \"A unique TPM on a device.\";\n leaf name {\n type string;\n description\n \"Unique system-generated name for a TPM on a device.\";\n }\n }\n\n grouping node-uptime {\n description\n \"Uptime in seconds of the node.\";\n leaf up-time {\n type uint32;\n description\n \"Uptime in seconds of this node reporting its data.\";\n }\n }\n\n grouping tpm12-attestation {\n description\n \"Contains an instance of cryptoprocessor measurements signed\n according to TPM 1.2. It is supplemented by unsigned\n Attester information.\";\n uses node-uptime;\n leaf pcr-data {\n type binary;\n description\n \"The value created and signed for the quote\n (type TPM_PCR_INFO_SHORT), i.e., the 'pcrData' part of\n a TPM1.2 Quote2 operation result.\";\n reference\n \"TPM1.2-Commands:\n TPM Main Part 3 Commands, Rev116,\n https://trustedcomputinggroup.org/wp-content/uploads\n /TPM-Main-Part-3-Commands_v1.2_rev116_01032011.pdf,\n Section 16.5\";\n }\n leaf version-info {\n type binary;\n description\n \"The version info (type TPM_CAP_VERSION_INFO),\n i.e., the 'versionInfo' part of a TPM1.2 Quote2\n operation result.\";\n reference\n \"TPM1.2-Commands:\n TPM Main Part 3 Commands, Rev116,\n https://trustedcomputinggroup.org/wp-content/uploads\n /TPM-Main-Part-3-Commands_v1.2_rev116_01032011.pdf,\n Section 16.5\";\n }\n leaf sig {\n type binary;\n description\n \"The signature generated across the signed data,\n i.e., the 'sig' part of a TPM1.2 Quote2 operation\n result.\";\n reference\n \"TPM1.2-Commands:\n TPM Main Part 3 Commands, Rev116,\n https://trustedcomputinggroup.org/wp-content/uploads\n /TPM-Main-Part-3-Commands_v1.2_rev116_01032011.pdf,\n Section 16.5\";\n }\n }\n\n grouping tpm20-attestation {\n description\n \"Contains an instance of cryptoprocessor measurements signed\n according to TPM 2.0. It is supplemented by unsigned\n Attester information.\";\n leaf quote-data {\n type binary;\n mandatory true;\n description\n \"A hash of the latest PCR values (and the hash algorithm\n used) that have been returned from an Attester for the\n selected PCRs and hash algorithms.\";\n reference\n \"TPM2.0-Structures:\n Trusted Platform Module Library Part 2: Structures,\n Revision 01.83, https://trustedcomputinggroup.org/\n wp-content/uploads/TPM-2.0-1.83-Part-2-Structures.pdf,\n Section 10.12.1\";\n }\n leaf quote-signature {\n type binary;\n description\n \"Quote signature returned by TPM Quote. The signature was\n generated using the key associated with the\n certificate 'name'.\";\n reference\n \"TPM2.0-Structures:\n Trusted Platform Module Library Part 2: Structures,\n Revision 01.83, https://trustedcomputinggroup.org/\n wp-content/uploads/TPM-2.0-1.83-Part-2-Structures.pdf,\n Section 11.2.1\";\n }\n uses node-uptime;\n list unsigned-pcr-values {\n description\n \"PCR values in each PCR bank. This might appear redundant\n with the TPM2B_DIGEST, but that digest is calculated across\n multiple PCRs. Having to verify across multiple PCRs does\n not necessarily make it easy for a Verifier to appraise just\n the minimum set of PCR information that has changed since\n the last received TPM2B_DIGEST. Put another way, why should\n a Verifier reconstruct the proper value of all PCR Quotes\n when only a single PCR has changed?\n To help this happen, if the Attester does know specific PCR\n values, the Attester can provide these individual values via\n 'unsigned-pcr-values'. By comparing this information to\n what has previously been validated, it is possible for a\n Verifier to confirm the Attester's signature while\n eliminating significant processing. Note that there should\n never be a result where an unsigned PCR value differs from\n what may be reconstructed from within the PCR quote and\n the event logs.\n If there is a difference, a signed result that has been\n verified from retrieved logs is considered definitive.\";\n uses tpm20-hash-algo;\n list pcr-values {\n key \"pcr-index\";\n description\n \"List of one PCR bank.\";\n leaf pcr-index {\n type pcr;\n description\n \"PCR index number.\";\n }\n leaf pcr-value {\n type binary;\n description\n \"PCR value.\";\n reference\n \"TPM2.0-Structures:\n Trusted Platform Module Library Part 2: Structures,\n Revision 01.83, https://trustedcomputinggroup.org/\n wp-content/uploads/TPM-2.0-1.83-Part-2-Structures.pdf,\n Section 10.9.7\";\n }\n }\n }\n }\n\n grouping log-identifier {\n description\n \"Identifier for type of log to be retrieved.\";\n leaf log-type {\n type identityref {\n base attested_event_log_type;\n }\n mandatory true;\n description\n \"The corresponding identity of the measurement log type.\";\n }\n }\n\n grouping boot-event-log {\n description\n \"Defines a specific instance of an event log entry\n and corresponding to the information used to\n extend the PCR.\";\n leaf event-number {\n type uint32;\n description\n \"Unique event number of this event, which monotonically\n increases within a given event log. The maximum event\n number should not be reached, nor is wrapping back to\n an earlier number supported.\";\n }\n leaf event-type {\n type uint32;\n description\n \"BIOS log event type.\";\n reference\n \"BIOS-Log:\n TCG PC Client Platform Firmware Profile Specification,\n https://trustedcomputinggroup.org/wp-content/uploads/\n TCG-PC-Client-Platform-Firmware-Profile-Version-1.06-\n Revision-52_pub-2.pdf, Section 10.4.1\";\n }\n leaf pcr-index {\n type pcr;\n description\n \"Defines the PCR index that this event extended.\";\n }\n list digest-list {\n description\n \"Hash of event data.\";\n leaf hash-algo {\n type identityref {\n base taa:hash;\n }\n description\n \"The hash scheme that is used to compress the event data in\n each of the leaf-list digest items.\";\n }\n leaf-list digest {\n type binary;\n description\n \"The hash of the event data using the algorithm of the\n 'hash-algo' against 'event data'.\";\n }\n }\n leaf event-size {\n type uint32;\n description\n \"Size of the event data.\";\n }\n leaf-list event-data {\n type binary;\n description\n \"The event data. This is a binary structure\n of size 'event-size'. For more on what\n might be recorded within this object\n see BIOS-Log, Section 10, which details\n viable events that might be recorded.\";\n reference\n \"BIOS-Log:\n TCG PC Client Platform Firmware Profile Specification,\n https://trustedcomputinggroup.org/wp-content/uploads/\n TCG-PC-Client-Platform-Firmware-Profile-Version-1.06-\n Revision-52_pub-2.pdf, Section 10\";\n }\n }\n\n grouping bios-event-log {\n description\n \"Measurement log created by the BIOS/UEFI.\";\n list bios-event-entry {\n key \"event-number\";\n description\n \"Ordered list of the TCG-described event log\n that extended the PCRs in the order they\n were logged.\";\n uses boot-event-log;\n }\n }\n\n grouping ima-event {\n description\n \"Defines a hash log extend event for IMA measurements.\";\n reference\n \"CEL:\n Canonical Event Log Format,\n https://www.trustedcomputinggroup.org/wp-content/uploads/\n TCG_IWG_CEL_v1_r0p41_pub.pdf, Section 4.3\";\n leaf event-number {\n type uint64;\n description\n \"Unique event number of this event, which monotonically\n increases. The maximum event number should not be\n reached, nor is wrapping back to an earlier number\n supported.\";\n }\n leaf ima-template {\n type string;\n description\n \"Name of the template used for event logs,\n e.g., ima, ima-ng, ima-sig.\";\n }\n leaf filename-hint {\n type string;\n description\n \"File name (including the path) that was measured.\";\n }\n leaf filedata-hash {\n type binary;\n description\n \"Hash of filedata as updated based upon the\n filedata-hash-algorithm.\";\n }\n leaf filedata-hash-algorithm {\n type string;\n description\n \"Algorithm used for filedata-hash.\";\n }\n leaf template-hash-algorithm {\n type string;\n description\n \"Algorithm used for template-hash.\";\n }\n leaf template-hash {\n type binary;\n description\n \"hash(filedata-hash, filename-hint)\";\n }\n leaf pcr-index {\n type pcr;\n description\n \"Defines the PCR index that this event extended.\";\n }\n leaf signature {\n type binary;\n description\n \"Digital file signature that provides a\n fingerprint for the file being measured.\";\n }\n }\n\n grouping ima-event-log {\n description\n \"Measurement log created by IMA.\";\n list ima-event-entry {\n key \"event-number\";\n description\n \"Ordered list of IMA event logs by event-number.\";\n uses ima-event;\n }\n }\n\n grouping network-equipment-boot-event-log {\n description\n \"Measurement log created by Network Equipment Boot. The\n Network Equipment Boot format is identical to the IMA\n format. In contrast to the IMA log, the Network Equipment\n Boot log includes every measurable event from an Attester,\n including the boot stages of BIOS, Bootloader, etc. In\n essence, the scope of events represented in this format\n combines the scope of BIOS events and IMA events.\";\n list boot-event-entry {\n key \"event-number\";\n description\n \"Ordered list of Network Equipment Boot event logs\n by event-number, using the IMA event format.\";\n uses ima-event;\n }\n }\n\n grouping event-logs {\n description\n \"A selector for the log and its type.\";\n choice attested_event_log_type {\n mandatory true;\n description\n \"Event log type determines the event log's content.\";\n case bios {\n if-feature \"bios\";\n description\n \"BIOS/UEFI event logs.\";\n container bios-event-logs {\n description\n \"BIOS/UEFI event logs.\";\n uses bios-event-log;\n }\n }\n case ima {\n if-feature \"ima\";\n description\n \"IMA event logs.\";\n container ima-event-logs {\n description\n \"IMA event logs.\";\n uses ima-event-log;\n }\n }\n case netequip_boot {\n if-feature \"netequip_boot\";\n description\n \"Network Equipment Boot event logs.\";\n container boot-event-logs {\n description\n \"Network Equipment Boot event logs.\";\n uses network-equipment-boot-event-log;\n }\n }\n }\n }\n\n /**********************/\n /* RPC operations */\n /**********************/\n\n rpc tpm12-challenge-response-attestation {\n if-feature \"taa:tpm12\";\n description\n \"This RPC accepts the input for TSS TPM 1.2 commands made to\n the attesting device.\";\n input {\n container tpm12-attestation-challenge {\n description\n \"This container includes every information element defined\n in the reference challenge-response interaction model for\n remote attestation. Corresponding values are based on\n TPM 1.2 structure definitions\";\n uses tpm12-pcr-selection;\n uses nonce;\n leaf-list certificate-name {\n if-feature \"tpm:mtpm\";\n type certificate-name-ref;\n must \"/tpm:rats-support-structures/tpm:tpms\"\n + \"/tpm:tpm[tpm:firmware-version='taa:tpm12']\"\n + \"/tpm:certificates/\"\n + \"/tpm:certificate[name=current()]\" {\n error-message \"Not an available TPM1.2 AIK certificate.\";\n }\n description\n \"When populated, the RPC will only get a Quote for the\n TPMs associated with these certificate(s).\";\n }\n }\n }\n output {\n list tpm12-attestation-response {\n unique \"certificate-name\";\n description\n \"The binary output of TPM 1.2 TPM_Quote/TPM_Quote2,\n including the PCR selection and other associated\n attestation evidence metadata.\";\n uses certificate-name-ref {\n description\n \"Certificate associated with this tpm12-attestation.\";\n }\n uses tpm12-attestation;\n }\n }\n }\n\n rpc tpm20-challenge-response-attestation {\n if-feature \"taa:tpm20\";\n description\n \"This RPC accepts the input for TSS TPM 2.0 commands of the\n managed device. Composite devices may contain several TPMs;\n /hardware/component/physical-index from the hardware\n management YANG module is used to refer to dedicated TPMs in\n composite devices; however, devices without TPMs are not\n covered.\";\n input {\n container tpm20-attestation-challenge {\n description\n \"This container includes every information element defined\n in the reference challenge-response interaction model for\n remote attestation. Corresponding values are based on\n TPM 2.0 structure definitions.\";\n uses nonce;\n uses tpm20-pcr-selection;\n leaf-list certificate-name {\n if-feature \"tpm:mtpm\";\n type certificate-name-ref;\n must \"/tpm:rats-support-structures/tpm:tpms\"\n + \"/tpm:tpm[tpm:firmware-version='taa:tpm20']\"\n + \"/tpm:certificates/\"\n + \"/tpm:certificate[name=current()]\" {\n error-message \"Not an available TPM2.0 AIK certificate.\";\n }\n description\n \"When populated, the RPC will only get a Quote for the\n TPMs associated with the certificates.\";\n }\n }\n }\n output {\n list tpm20-attestation-response {\n unique \"certificate-name\";\n description\n \"The binary output of TPM2_Quote from one TPM of the\n node which is identified by node-id: an attestation\n structure (TPMS_ATTEST), including a length, and a\n signature (TPMT_SIGNATURE) over that structure.\";\n reference\n \"TPM2.0-Structures:\n Trusted Platform Module Library Part 2: Structures,\n Revision 01.83, https://trustedcomputinggroup.org/\n wp-content/uploads/TPM-2.0-1.83-Part-2-Structures.pdf,\n Section 10.12.12\";\n uses certificate-name-ref {\n description\n \"Certificate associated with this tpm20-attestation.\";\n }\n uses tpm20-attestation;\n }\n }\n }\n\n rpc log-retrieval {\n description\n \"Log entries are identified either via indices or by providing\n the last line received. The number of lines returned can be\n limited. The type of log is a choice that can be augmented.\";\n input {\n uses log-identifier;\n list log-selector {\n description\n \"Only log entries that meet all of the provided selection\n criteria are to be returned by the RPC output.\";\n leaf-list name {\n type string;\n description\n \"Name of one or more unique TPMs on a device. If this\n object exists, a selection should pull only the objects\n related to these TPM(s). If it does not exist, all\n qualifying TPMs that are 'hardware-based' equals true\n on the device are selected. When this selection\n criteria is provided, it will be considered as a logical\n AND with any other selection criteria provided.\";\n }\n choice index-type {\n description\n \"Last log entry received, log index number, or\n timestamp.\";\n case last-entry {\n description\n \"The last entry of the log already retrieved.\";\n leaf last-entry-value {\n type binary;\n description\n \"Content of a log event that matches 1:1 with a\n unique event record contained within the log. Log\n entries after this will be passed to the\n requester. Note: if log entry values are not\n unique, this MUST return an error.\";\n }\n }\n case index {\n description\n \"Numeric index of the last log entry retrieved, or\n zero.\";\n leaf last-index-number {\n type uint64;\n description\n \"The last numeric index number of a log entry.\n Zero means to start at the beginning of the log.\n Entries after this will be passed to the\n requester.\";\n }\n }\n case timestamp {\n leaf timestamp {\n type yang:date-and-time;\n description\n \"Timestamp from which to start the extraction. The\n next log entry after this timestamp is to\n be sent.\";\n }\n description\n \"Timestamp from which to start the extraction.\";\n }\n }\n leaf log-entry-quantity {\n type uint16;\n description\n \"The number of log entries to be returned. If omitted, it\n means all of them.\";\n }\n }\n }\n output {\n container system-event-logs {\n description\n \"The requested data of the measurement event logs.\";\n list node-data {\n unique \"name\";\n description\n \"Event logs of a node in a distributed system\n identified by the node name.\";\n uses tpm-name;\n uses node-uptime;\n container log-result {\n description\n \"The requested entries of the corresponding log.\";\n uses event-logs;\n }\n }\n }\n }\n }\n\n /****************************************/\n /* Config and Oper accessible nodes */\n /****************************************/\n\n container rats-support-structures {\n description\n \"The datastore definition enabling Verifiers or Relying\n Parties to discover the information necessary to use the\n remote attestation RPCs appropriately.\";\n container compute-nodes {\n if-feature \"tpm:mtpm\";\n description\n \"Holds the set of device subsystems/components in this\n composite device that support TPM operations.\";\n list compute-node {\n key \"node-id\";\n unique \"node-name\";\n config false;\n min-elements 2;\n description\n \"A component within this composite device that\n supports TPM operations.\";\n leaf node-id {\n type string;\n description\n \"ID of the compute node, such as Board Serial Number.\";\n }\n leaf node-physical-index {\n if-feature \"hw:entity-mib\";\n type int32 {\n range \"1..2147483647\";\n }\n config false;\n description\n \"The entPhysicalIndex for the compute node.\";\n reference\n \"RFC 6933: Entity MIB (Version 4) - entPhysicalIndex\";\n }\n leaf node-name {\n type string;\n description\n \"Name of the compute node.\";\n }\n leaf node-location {\n type string;\n description\n \"Location of the compute node, such as slot number.\";\n }\n }\n }\n container tpms {\n description\n \"Holds the set of TPMs within an Attester.\";\n list tpm {\n key \"name\";\n unique \"path\";\n description\n \"A list of TPMs in this composite device that RATS\n can be conducted with.\";\n uses tpm-name;\n leaf hardware-based {\n type boolean;\n config false;\n mandatory true;\n description\n \"System-generated indication of whether this is a\n hardware-based TPM.\";\n }\n leaf physical-index {\n if-feature \"hw:entity-mib\";\n type int32 {\n range \"1..2147483647\";\n }\n config false;\n description\n \"The entPhysicalIndex for the TPM.\";\n reference\n \"RFC 6933: Entity MIB (Version 4) - entPhysicalIndex\";\n }\n leaf path {\n type string;\n config false;\n description\n \"Device path to a unique TPM on a device. This can\n change across reboots.\";\n }\n leaf compute-node {\n if-feature \"tpm:mtpm\";\n type compute-node-ref;\n config false;\n mandatory true;\n description\n \"Indicates the compute node measured by this TPM.\";\n }\n leaf manufacturer {\n type string;\n config false;\n description\n \"TPM manufacturer name.\";\n }\n leaf firmware-version {\n type identityref {\n base taa:cryptoprocessor;\n }\n mandatory true;\n description\n \"Identifies the cryptoprocessor API set supported. This\n is automatically configured by the device and should not\n be changed.\";\n }\n uses tpm12-hash-algo {\n when \"derived-from-or-self(firmware-version, 'taa:tpm12')\";\n if-feature \"taa:tpm12\";\n refine \"tpm12-hash-algo\" {\n description\n \"The hash algorithm overwrites the default used for\n PCRs on this TPM1.2-compliant cryptoprocessor.\";\n }\n }\n leaf-list tpm12-pcrs {\n when \"derived-from-or-self(../firmware-version, \"\n + \"'taa:tpm12')\";\n if-feature \"taa:tpm12\";\n type pcr;\n description\n \"The PCRs that may be extracted from this TPM1.2-\n compliant cryptoprocessor.\";\n }\n list tpm20-pcr-bank {\n when \"derived-from-or-self(../firmware-version, \"\n + \"'taa:tpm20')\";\n if-feature \"taa:tpm20\";\n key \"tpm20-hash-algo\";\n description\n \"Specifies the list of PCRs that may be extracted for\n a specific hash algorithm on this TPM2-compliant\n cryptoprocessor. A bank is a set of PCRs that are\n extended using a particular hash algorithm.\";\n reference\n \"TPM2.0-Structures:\n Trusted Platform Module Library Part 2: Structures,\n Revision 01.83, https://trustedcomputinggroup.org/\n wp-content/uploads/TPM-2.0-1.83-Part-2-Structures.pdf,\n Section 10.9.7\";\n leaf tpm20-hash-algo {\n type identityref {\n base taa:hash;\n }\n must '/tpm:rats-support-structures'\n + '/tpm:attester-supported-algos'\n + '/tpm:tpm20-hash' {\n error-message \"This platform does not support \"\n + \"tpm20-hash-algo\";\n }\n description\n \"The hash scheme actively being used to hash\n one or more TPM2.0 PCRs.\";\n }\n leaf-list pcr-index {\n type tpm:pcr;\n description\n \"Defines which TPM2.0 PCRs are available to be\n extracted.\";\n }\n }\n leaf status {\n type enumeration {\n enum operational {\n value 0;\n description\n \"The TPM currently is running normally and\n is ready to accept and process TPM quotes.\";\n reference\n \"TPM2.0-Arch: Trusted Platform Module Library\n Part 1: Architecture,\n https://trustedcomputinggroup.org/wp-content/\n uploads/TPM-2.0-1.83-Part-1-Architecture.pdf,\n Section 12\";\n }\n enum non-operational {\n value 1;\n description\n \"TPM is in a state such as startup or shutdown, which\n precludes the processing of TPM quotes.\";\n }\n }\n config false;\n mandatory true;\n description\n \"TPM chip self-test status.\";\n }\n container certificates {\n description\n \"The TPM's certificates, including EK Certificates\n and Attestation Key Certificates.\";\n list certificate {\n key \"name\";\n description\n \"Three types of certificates can be accessed via\n this statement, including Initial Attestation\n Key Certificate, Local Attestation Key Certificate, or\n Endorsement Key Certificate.\";\n leaf name {\n type string;\n description\n \"An arbitrary name uniquely identifying a certificate\n associated with a key within a TPM.\";\n }\n leaf keystore-ref {\n if-feature \"ks:central-keystore-supported\";\n if-feature \"ks:asymmetric-keys\";\n type leafref {\n path \"/ks:keystore/ks:asymmetric-keys\"\n + \"/ks:asymmetric-key/ks:name\";\n }\n description\n \"A reference to a specific certificate of an\n asymmetric key in the keystore.\";\n }\n leaf type {\n type enumeration {\n enum endorsement-certificate {\n value 0;\n description\n \"Endorsement Key (EK) Certificate type.\";\n reference\n \"TPM2.0-Key:\n TPM 2.0 Keys for Device Identity and Attestation\n https://trustedcomputinggroup.org/wp-content/\n uploads/TPM-2p0-Keys-for-Device-Identity-\n and-Attestation_v1_r12_pub10082021.pdf,\n Section 3.11\";\n }\n enum initial-attestation-certificate {\n value 1;\n description\n \"Initial Attestation Key (IAK) Certificate\n type.\";\n reference\n \"TPM2.0-Key:\n TPM 2.0 Keys for Device Identity and Attestation\n https://trustedcomputinggroup.org/wp-content/\n uploads/TPM-2p0-Keys-for-Device-Identity-\n and-Attestation_v1_r12_pub10082021.pdf,\n Section 3.2\";\n }\n enum local-attestation-certificate {\n value 2;\n description\n \"Local Attestation Key (LAK) Certificate type.\";\n reference\n \"TPM2.0-Key:\n TPM 2.0 Keys for Device Identity and Attestation\n https://trustedcomputinggroup.org/wp-content/\n uploads/TPM-2p0-Keys-for-Device-Identity-\n and-Attestation_v1_r12_pub10082021.pdf,\n Section 3.2\";\n }\n }\n description\n \"Function supported by this certificate from within\n the TPM.\";\n }\n }\n }\n }\n }\n container attester-supported-algos {\n description\n \"Identifies which TPM algorithms are available for use on an\n attesting platform.\";\n leaf-list tpm12-asymmetric-signing {\n when \"../../tpm:tpms\"\n + \"/tpm:tpm[tpm:firmware-version='taa:tpm12']\";\n if-feature \"taa:tpm12\";\n type identityref {\n base taa:asymmetric;\n }\n description\n \"Platform-supported TPM1.2 asymmetric algorithms.\";\n }\n leaf-list tpm12-hash {\n when \"../../tpm:tpms\"\n + \"/tpm:tpm[tpm:firmware-version='taa:tpm12']\";\n if-feature \"taa:tpm12\";\n type identityref {\n base taa:hash;\n }\n description\n \"Platform-supported TPM1.2 hash algorithms.\";\n }\n leaf-list tpm20-asymmetric-signing {\n when \"../../tpm:tpms\"\n + \"/tpm:tpm[tpm:firmware-version='taa:tpm20']\";\n if-feature \"taa:tpm20\";\n type identityref {\n base taa:asymmetric;\n }\n description\n \"Platform-supported TPM2.0 asymmetric algorithms.\";\n }\n leaf-list tpm20-hash {\n when \"../../tpm:tpms\"\n + \"/tpm:tpm[tpm:firmware-version='taa:tpm20']\";\n if-feature \"taa:tpm20\";\n type identityref {\n base taa:hash;\n }\n description\n \"Platform-supported TPM2.0 hash algorithms.\";\n }\n }\n }\n}\n\n\n Figure 1", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "2.1.2. ietf-tcg-algs", + "section_title": true, + "ja": "2.1.2. IETF-TCG-ALGS" + }, + { + "indent": 3, + "text": "This document has encoded the TCG Algorithm definitions of Table 3 of [TCG-Algos], revision 1.32. By including this full table as a separate YANG file within this document, it is possible for other YANG modules to leverage the contents of this module. Specific references to [TPM1.2-Structures], [TPM2.0], [RFC2104], [RFC8017], [RFC8032], [ISO-IEC-9797-1], [ISO-IEC-9797-2], [ISO-IEC-10116], [ISO-IEC-10118-3], [ISO-IEC-14888-3], [ISO-IEC-15946-1], [ISO-IEC-18033-3], [IEEE-Std-1363-2000], [IEEE-Std-1363a-2004], [NIST-FIPS-202], [NIST-SP800-38C], [NIST-SP800-38D], [NIST-SP800-38F], [NIST-SP800-56A], and [NIST-SP800-108] exist within the YANG module.", + "ja": "このドキュメントは、[TCG-Algos]の表3のTCGアルゴリズム定義をエンコードしました。このフルテーブルをこのドキュメント内に別のYangファイルとして含めることにより、他のYangモジュールがこのモジュールの内容を活用することができます。[TPM1.2構造]、[TPM2.0]、[RFC2104]、[RFC8017]、[RFC8032]、[ISO-IEC-9797-1]、[ISO-IEC-9797-2]、[ISO-IEC-9797-2]への特定の参照ISO-IEC-10116]、[ISO-IEC-10118-3]、[ISO-IEC-14888-3]、[ISO-IEC-15946-1]、[ISO-IEC-18033-3]、[IEEE-STD-1363-2000]、[IEEE-STD-1363A-2004]、[nist-fips-202]、[nist-sp800-38c]、[nist-sp800-38d]、[nist-sp800-38f]、[nist-sp800-56a]、および[nist-sp800-108]はヤンモジュール内に存在します。" + }, + { + "indent": 0, + "text": "2.1.2.1. Features", + "section_title": true, + "ja": "2.1.2.1. 特徴" + }, + { + "indent": 3, + "text": "There are two types of features supported: 'tpm12' and 'tpm20'. Support for either of these features indicates that a cryptoprocessor supporting the corresponding type of TCG TPM API is present on an Attester. Most commonly, only one type of cryptoprocessor will be available on an Attester.", + "ja": "サポートされている機能には、「TPM12」と「TPM20」という2種類の機能があります。これらの機能のいずれかをサポートすることは、対応するタイプのTCG TPM APIをサポートするクリプトプロセッサがastesterに存在することを示しています。最も一般的には、指標に利用できるようになります。" + }, + { + "indent": 0, + "text": "2.1.2.2. Identities", + "section_title": true, + "ja": "2.1.2.2. アイデンティティ" + }, + { + "indent": 3, + "text": "There are three types of identities in this model:", + "ja": "このモデルには、3種類のアイデンティティがあります。" + }, + { + "indent": 8, + "text": "1. Cryptographic functions supported by a TPM algorithm; these include 'asymmetric', 'symmetric', 'hash', 'signing', 'anonymous_signing', 'encryption_mode', 'method', and 'object_type'. The definitions of each of these are in Table 2 of [TCG-Algos].", + "ja": "1. TPMアルゴリズムによってサポートされる暗号化関数。これらには、「非対称」、「対称」、「ハッシュ」、「署名」、「anonymous_singe」、「encryption_mode '、' method '、および' object_type 'が含まれます。これらのそれぞれの定義は、[TCG-Algos]の表2にあります。" + }, + { + "indent": 8, + "text": "2. API specifications for TPM types: 'tpm12' and 'tpm20'", + "ja": "2. TPMタイプのAPI仕様：「TPM12」および「TPM20」" + }, + { + "indent": 8, + "text": "3. Specific algorithm types: Each algorithm type defines which cryptographic functions may be supported, and on which type of API specification. It is not required that an implementation of a specific TPM will support all algorithm types. The contents of each specific algorithm mirrors the contents of Table 3 of [TCG-Algos].", + "ja": "3. 特定のアルゴリズムタイプ：各アルゴリズムタイプは、どの暗号化関数がサポートされるか、どのタイプのAPI仕様を定義します。特定のTPMの実装がすべてのアルゴリズムタイプをサポートすることは必須ではありません。各特定のアルゴリズムの内容は、[TCG-Algos]の表3の内容を反映しています。" + }, + { + "indent": 0, + "text": "2.1.2.3. YANG Module", + "section_title": true, + "ja": "2.1.2.3. ヤンモジュール" + }, + { + "indent": 3, + "text": "module ietf-tcg-algs {\n yang-version 1.1;\n namespace \"urn:ietf:params:xml:ns:yang:ietf-tcg-algs\";\n prefix taa;\n\n organization\n \"IETF RATS (Remote ATtestation procedureS) Working Group\";\n contact\n \"WG Web: \n WG List: \n Author: Eric Voit \";\n description\n \"This module defines identities for asymmetric algorithms.\n\n The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL\n NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',\n 'MAY', and 'OPTIONAL' in this document are to be interpreted as\n described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,\n they appear in all capitals, as shown here.\n\n Copyright (c) 2024 IETF Trust and the persons identified as\n authors of the code. All rights reserved.\n\n Redistribution and use in source and binary forms, with or\n without modification, is permitted pursuant to, and subject to\n the license terms contained in, the Revised BSD License set\n forth in Section 4.c of the IETF Trust's Legal Provisions\n Relating to IETF Documents\n (https://trustee.ietf.org/license-info).\n\n This version of this YANG module is part of RFC 9684; see the\n RFC itself for full legal notices.\";\n\n revision 2024-12-05 {\n description\n \"Initial version\";\n reference\n \"RFC 9684: A YANG Data Model for Challenge-Response-Based\n Remote Attestation (CHARRA) Procedures Using Trusted Platform\n Modules (TPMs)\";\n }\n\n /*****************/\n /* Features */\n /*****************/\n\n feature tpm12 {\n description\n \"This feature indicates algorithm support for the TPM 1.2 API\n per Section 4.8 of TPM1.2-Structures.\";\n reference\n \"TPM1.2-Structures: TPM Main Part 2 TPM Structures,\n https://trustedcomputinggroup.org/wp-content/uploads/\n TPM-Main-Part-2-TPM-Structures_v1.2_rev116_01032011.pdf\n TPM_ALGORITHM_ID values, Section 4.8\";\n }\n\n feature tpm20 {\n description\n \"This feature indicates algorithm support for the TPM 2.0 API\n per Section 11.4 of Trusted Platform Module Library Part 1:\n Architecture.\";\n reference\n \"TPM2.0-Arch: Trusted Platform Module Library Part 1:\n Architecture, https://trustedcomputinggroup.org/wp-content/\n uploads/TPM-2.0-1.83-Part-1-Architecture.pdf, Section 11.4\";\n }\n\n /*****************/\n /* Identities */\n /*****************/\n\n identity asymmetric {\n description\n \"A TCG-recognized asymmetric algorithm with a public and\n private key.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 2,\n https://trustedcomputinggroup.org/resource/\n tcg-algorithm-registry/TCG-_Algorithm_Registry_r1p32_pub\";\n }\n\n identity symmetric {\n description\n \"A TCG-recognized symmetric algorithm with only a private\n key.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 2\";\n }\n\n identity hash {\n description\n \"A TCG-recognized hash algorithm that compresses input data to\n a digest value or indicates a method that uses a hash.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 2\";\n }\n\n identity signing {\n description\n \"A TCG-recognized signing algorithm\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 2\";\n }\n\n identity anonymous_signing {\n description\n \"A TCG-recognized anonymous signing algorithm.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 2\";\n }\n\n identity encryption_mode {\n description\n \"A TCG-recognized encryption mode.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 2\";\n }\n\n identity method {\n description\n \"A TCG-recognized method such as a mask generation function.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 2\";\n }\n\n identity object_type {\n description\n \"A TCG-recognized object type.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 2\";\n }\n\n identity cryptoprocessor {\n description\n \"Base identity identifying a crytoprocessor.\";\n }\n\n identity tpm12 {\n if-feature \"tpm12\";\n base cryptoprocessor;\n description\n \"Supportable by a TPM 1.2.\";\n reference\n \"TPM1.2-Structures:\n TPM Main Part 2 TPM Structures,\n https://trustedcomputinggroup.org/wp-content/uploads/\n TPM-Main-Part-2-TPM-Structures_v1.2_rev116_01032011.pdf\n TPM_ALGORITHM_ID values, Section 4.8\";\n }\n\n identity tpm20 {\n if-feature \"tpm20\";\n base cryptoprocessor;\n description\n \"Supportable by a TPM 2.0\";\n reference\n \"TPM2.0-Structures:\n Trusted Platform Module Library Part 2: Structures,\n Revision 01.83, https://trustedcomputinggroup.org/\n wp-content/uploads/TPM-2.0-1.83-Part-2-Structures.pdf\";\n }\n\n identity TPM_ALG_RSA {\n if-feature \"tpm12 or tpm20\";\n base tpm12;\n base tpm20;\n base asymmetric;\n base object_type;\n description\n \"RSA algorithm.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and\n RFC 8017. ALG_ID: 0x0001\";\n }\n\n identity TPM_ALG_TDES {\n if-feature \"tpm12\";\n base tpm12;\n base symmetric;\n description\n \"Block cipher with various key sizes (Triple Data Encryption\n Algorithm, commonly called Triple Data Encryption Standard)\n Note: Was banned in TPM 1.2, v94\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and\n ISO/IEC 18033-3. ALG_ID: 0x0003\";\n }\n\n identity TPM_ALG_SHA1 {\n if-feature \"tpm12 or tpm20\";\n base hash;\n base tpm12;\n base tpm20;\n description\n \"SHA1 algorithm - Deprecated due to insufficient cryptographic\n protection. However, it is still useful for hash algorithms\n where protection is not required.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry Rev1.34, Table 3, and\n ISO/IEC 10118-3. ALG_ID: 0x0004\";\n }\n\n identity TPM_ALG_HMAC {\n if-feature \"tpm12 or tpm20\";\n base tpm12;\n base tpm20;\n base hash;\n base signing;\n description\n \"Hash Message Authentication Code (HMAC) algorithm.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and\n ISO/IEC 9797-2, and\n RFC 2104. ALG_ID: 0x0005\";\n }\n\n identity TPM_ALG_AES {\n if-feature \"tpm12\";\n base tpm12;\n base symmetric;\n description\n \"The AES algorithm with various key sizes.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and\n ISO/IEC 18033-3. ALG_ID: 0x0006\";\n }\n\n identity TPM_ALG_MGF1 {\n if-feature \"tpm20\";\n base tpm20;\n base hash;\n base method;\n description\n \"Hash-based mask-generation function.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and\n IEEE Std 1363-2000, and\n IEEE Std 1363a-2004.\n ALG_ID: 0x0007\";\n }\n\n identity TPM_ALG_KEYEDHASH {\n if-feature \"tpm20\";\n base tpm20;\n base hash;\n base object_type;\n description\n \"An encryption or signing algorithm using a keyed hash. These\n may use XOR for encryption or an HMAC for signing and may\n also refer to a data object that is neither signing nor\n encrypting.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3.\n ALG_ID: 0x0008\";\n }\n\n identity TPM_ALG_XOR {\n if-feature \"tpm12 or tpm20\";\n base tpm12;\n base tpm20;\n base hash;\n base symmetric;\n description\n \"The XOR encryption algorithm.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3.\n ALG_ID: 0x000A\";\n }\n\n identity TPM_ALG_SHA256 {\n if-feature \"tpm20\";\n base tpm20;\n base hash;\n description\n \"The SHA-256 algorithm.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and\n ISO/IEC 10118-3. ALG_ID: 0x000B\";\n }\n\n identity TPM_ALG_SHA384 {\n if-feature \"tpm20\";\n base tpm20;\n base hash;\n description\n \"The SHA-384 algorithm.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and\n ISO/IEC 10118-3. ALG_ID: 0x000C\";\n }\n\n identity TPM_ALG_SHA512 {\n if-feature \"tpm20\";\n base tpm20;\n base hash;\n description\n \"The SHA-512 algorithm.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and\n ISO/IEC 10118-3. ALG_ID: 0x000D\";\n }\n\n identity TPM_ALG_NULL {\n if-feature \"tpm20\";\n base tpm20;\n description\n \"Null algorithm.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3.\n ALG_ID: 0x0010\";\n }\n\n identity TPM_ALG_SM3_256 {\n if-feature \"tpm20\";\n base tpm20;\n base hash;\n description\n \"The ShangMi 3 (SM3) hash algorithm.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and\n ISO/IEC 10118-3:2018. ALG_ID: 0x0012\";\n }\n\n identity TPM_ALG_SM4 {\n if-feature \"tpm20\";\n base tpm20;\n base symmetric;\n description\n \"ShangMi 4 (SM4) symmetric block cipher.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3.\n ALG_ID: 0x0013\";\n }\n\n identity TPM_ALG_RSASSA {\n if-feature \"tpm20\";\n base tpm20;\n base asymmetric;\n base signing;\n description\n \"Signature algorithm defined in Section 8.2\n (RSASSA-PKCS1-v1_5) of RFC 8017.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and\n RFC 8017. ALG_ID: 0x0014\";\n }\n\n identity TPM_ALG_RSAES {\n if-feature \"tpm20\";\n base tpm20;\n base asymmetric;\n base encryption_mode;\n description\n \"Signature algorithm defined in Section 7.2\n (RSAES-PKCS1-v1_5) of RFC 8017.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and\n RFC 8017. ALG_ID: 0x0015\";\n }\n\n identity TPM_ALG_RSAPSS {\n if-feature \"tpm20\";\n base tpm20;\n base asymmetric;\n base signing;\n description\n \"Padding algorithm defined in Section 8.1 (RSASSA-PSS)\n of RFC 8017.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and\n RFC 8017. ALG_ID: 0x0016\";\n }\n\n identity TPM_ALG_OAEP {\n if-feature \"tpm20\";\n base tpm20;\n base asymmetric;\n base encryption_mode;\n description\n \"Padding algorithm defined in Section 7.1 (RSAES-OAEP)\n of RFC 8017.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and\n RFC 8017. ALG_ID: 0x0017\";\n }\n\n identity TPM_ALG_ECDSA {\n if-feature \"tpm20\";\n base tpm20;\n base asymmetric;\n base signing;\n description\n \"Signature algorithm using elliptic curve cryptography (ECC).\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and\n ISO/IEC 14888-3. ALG_ID: 0x0018\";\n }\n\n identity TPM_ALG_ECDH {\n if-feature \"tpm20\";\n base tpm20;\n base asymmetric;\n base method;\n description\n \"Secret sharing using ECC.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and\n NIST SP800-56A. ALG_ID: 0x0019\";\n }\n\n identity TPM_ALG_ECDAA {\n if-feature \"tpm20\";\n base tpm20;\n base asymmetric;\n base signing;\n base anonymous_signing;\n description\n \"Elliptic-curve-based, anonymous signing scheme.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and\n TCG TPM 2.0 Library. ALG_ID: 0x001A\";\n }\n\n identity TPM_ALG_SM2 {\n if-feature \"tpm20\";\n base tpm20;\n base asymmetric;\n base signing;\n base encryption_mode;\n base method;\n description\n \"SM2 - depending on context, either an elliptic-curve based,\n signature algorithm, an encryption scheme, or a key exchange\n protocol.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3.\n ALG_ID: 0x001B\";\n }\n\n identity TPM_ALG_ECSCHNORR {\n if-feature \"tpm20\";\n base tpm20;\n base asymmetric;\n base signing;\n description\n \"Elliptic-curve-based Schnorr signature.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3.\n ALG_ID: 0x001C\";\n }\n\n identity TPM_ALG_ECMQV {\n if-feature \"tpm20\";\n base tpm20;\n base asymmetric;\n base method;\n description\n \"Two-phase elliptic-curve key.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and\n NIST SP800-56A. ALG_ID: 0x001D\";\n }\n\n identity TPM_ALG_KDF1_SP800_56A {\n if-feature \"tpm20\";\n base tpm20;\n base hash;\n base method;\n description\n \"Concatenation key derivation function.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and\n NIST SP800-56A (approved alternative1) Section 5.8.1.\n ALG_ID: 0x0020\";\n }\n\n identity TPM_ALG_KDF2 {\n if-feature \"tpm20\";\n base tpm20;\n base hash;\n base method;\n description\n \"Key derivation function.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and\n IEEE 1363a-2004, KDF2, Section 13.2. ALG_ID: 0x0021\";\n }\n\n identity TPM_ALG_KDF1_SP800_108 {\n base TPM_ALG_KDF2;\n description\n \"A key derivation method.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3 and\n NIST SP800-108, Section 4.1, KDF. ALG_ID: 0x0022\";\n }\n\n identity TPM_ALG_ECC {\n if-feature \"tpm20\";\n base tpm20;\n base asymmetric;\n base object_type;\n description\n \"Prime field ECC.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and\n ISO/IEC 15946-1. ALG_ID: 0x0023\";\n }\n\n identity TPM_ALG_SYMCIPHER {\n if-feature \"tpm20\";\n base tpm20;\n base symmetric;\n base object_type;\n description\n \"Object type for a symmetric block cipher.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and\n TCG TPM 2.0 Library. ALG_ID: 0x0025\";\n }\n\n identity TPM_ALG_CAMELLIA {\n if-feature \"tpm20\";\n base tpm20;\n base symmetric;\n description\n \"The Camellia algorithm.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and\n ISO/IEC 18033-3. ALG_ID: 0x0026\";\n }\n\n identity TPM_ALG_SHA3_256 {\n if-feature \"tpm20\";\n base tpm20;\n base hash;\n description\n \"ISO/IEC 10118-3 - the SHA-256 algorithm.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and\n NIST FIPS 202. ALG_ID: 0x0027\";\n }\n\n identity TPM_ALG_SHA3_384 {\n if-feature \"tpm20\";\n base tpm20;\n base hash;\n description\n \"The SHA-384 algorithm.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and\n NIST FIPS 202. ALG_ID: 0x0028\";\n }\n\n identity TPM_ALG_SHA3_512 {\n if-feature \"tpm20\";\n base tpm20;\n base hash;\n description\n \"The SHA-512 algorithm.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and\n NIST FIPS 202. ALG_ID: 0x0029\";\n }\n\n identity TPM_ALG_CMAC {\n if-feature \"tpm20\";\n base tpm20;\n base symmetric;\n base signing;\n description\n \"Block Cipher-based Message Authentication Code (CMAC).\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and\n ISO/IEC 9797-1:2011, Algorithm 5. ALG_ID: 0x003F\";\n }\n\n identity TPM_ALG_CTR {\n if-feature \"tpm20\";\n base tpm20;\n base symmetric;\n base encryption_mode;\n description\n \"Counter mode.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and\n ISO/IEC 10116. ALG_ID: 0x0040\";\n }\n\n identity TPM_ALG_OFB {\n base tpm20;\n base symmetric;\n base encryption_mode;\n description\n \"Output Feedback mode.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and\n ISO/IEC 10116. ALG_ID: 0x0041\";\n }\n\n identity TPM_ALG_CBC {\n if-feature \"tpm20\";\n base tpm20;\n base symmetric;\n base encryption_mode;\n description\n \"Cipher Block Chaining mode.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and\n ISO/IEC 10116. ALG_ID: 0x0042\";\n }\n\n identity TPM_ALG_CFB {\n if-feature \"tpm20\";\n base tpm20;\n base symmetric;\n base encryption_mode;\n description\n \"Cipher Feedback mode.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and\n ISO/IEC 10116. ALG_ID: 0x0043\";\n }\n\n identity TPM_ALG_ECB {\n if-feature \"tpm20\";\n base tpm20;\n base symmetric;\n base encryption_mode;\n description\n \"Electronic Codebook mode.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and\n ISO/IEC 10116. ALG_ID: 0x0044\";\n }\n\n identity TPM_ALG_CCM {\n if-feature \"tpm20\";\n base tpm20;\n base symmetric;\n base signing;\n base encryption_mode;\n description\n \"Counter with Cipher Block Chaining--Message Authentication\n Code (CCM).\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and\n NIST SP800-38C. ALG_ID: 0x0050\";\n }\n\n identity TPM_ALG_GCM {\n if-feature \"tpm20\";\n base tpm20;\n base symmetric;\n base signing;\n base encryption_mode;\n description\n \"Galois/Counter Mode (GCM).\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and\n NIST SP800-38D. ALG_ID: 0x0051\";\n }\n\n identity TPM_ALG_KW {\n if-feature \"tpm20\";\n base tpm20;\n base symmetric;\n base signing;\n base encryption_mode;\n description\n \"AES Key Wrap (KW).\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and\n NIST SP800-38F. ALG_ID: 0x0052\";\n }\n\n identity TPM_ALG_KWP {\n if-feature \"tpm20\";\n base tpm20;\n base symmetric;\n base signing;\n base encryption_mode;\n description\n \"AES Key Wrap with Padding (KWP).\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and\n NIST SP800-38F. ALG_ID: 0x0053\";\n }\n\n identity TPM_ALG_EAX {\n if-feature \"tpm20\";\n base tpm20;\n base symmetric;\n base signing;\n base encryption_mode;\n description\n \"Authenticated-Encryption Mode.\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and\n NIST SP800-38F. ALG_ID: 0x0054\";\n }\n\n identity TPM_ALG_EDDSA {\n if-feature \"tpm20\";\n base tpm20;\n base asymmetric;\n base signing;\n description\n \"Edwards-curve Digital Signature Algorithm (PureEdDSA).\";\n reference\n \"TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and\n RFC 8032. ALG_ID: 0x0060\";\n }\n}", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Note that not all cryptographic functions are required for use by ietf-tpm-remote-attestation.yang. However, the full definition of Table 3 of [TCG-Algos] will allow use by additional YANG specifications.", + "ja": "IETF-TPM-Remote-Attestation.yangで使用するためにすべての暗号化関数が必要なわけではないことに注意してください。ただし、[TCG-Algos]の表3の完全な定義により、追加のYang仕様による使用が可能になります。" + }, + { + "indent": 0, + "text": "3. IANA Considerations", + "section_title": true, + "ja": "3. IANAの考慮事項" + }, + { + "indent": 3, + "text": "This document registers the following namespace URIs in the [XML-Registry] per [RFC3688]:", + "ja": "このドキュメントは、[rfc3688]ごとに[xml-registry]の次の名前空間URIを登録します。" + }, + { + "indent": 3, + "text": "URI:", + "ja": "URI:" + }, + { + "indent": 12, + "text": "urn:ietf:params:xml:ns:yang:ietf-tpm-remote-attestation", + "ja": "urn：ietf：params：xml：ns：yang：ietf-tpm-remote-attestation" + }, + { + "indent": 3, + "text": "Registrant Contact:", + "ja": "登録者の連絡先：" + }, + { + "indent": 12, + "text": "The IESG.", + "ja": "IESG。" + }, + { + "indent": 3, + "text": "XML:", + "ja": "XML:" + }, + { + "indent": 12, + "text": "N/A; the requested URI is an XML namespace.", + "ja": "n/a;要求されたURIはXMLネームスペースです。" + }, + { + "indent": 3, + "text": "URI:", + "ja": "URI:" + }, + { + "indent": 12, + "text": "urn:ietf:params:xml:ns:yang:ietf-tcg-algs", + "ja": "urn：ietf：params：xml：ns：yang：ietf-tcg-algs" + }, + { + "indent": 3, + "text": "Registrant Contact:", + "ja": "登録者の連絡先：" + }, + { + "indent": 12, + "text": "The IESG.", + "ja": "IESG。" + }, + { + "indent": 3, + "text": "XML:", + "ja": "XML:" + }, + { + "indent": 12, + "text": "N/A; the requested URI is an XML namespace.", + "ja": "n/a;要求されたURIはXMLネームスペースです。" + }, + { + "indent": 3, + "text": "This document registers the following YANG modules in the registry [YANG-Parameters] per Section 14 of [RFC6020]:", + "ja": "このドキュメントでは、[RFC6020]のセクション14ごとにレジストリ[Yang-Parameters]の次のYangモジュールを登録します。" + }, + { + "indent": 3, + "text": "Name:", + "ja": "名前：" + }, + { + "indent": 12, + "text": "ietf-tpm-remote-attestation", + "ja": "IETF-TPM-Remote-Attestation" + }, + { + "indent": 3, + "text": "Namespace:", + "ja": "名前空間：" + }, + { + "indent": 12, + "text": "urn:ietf:params:xml:ns:yang:ietf-tpm-remote-attestation", + "ja": "urn：ietf：params：xml：ns：yang：ietf-tpm-remote-attestation" + }, + { + "indent": 3, + "text": "Prefix:", + "ja": "プレフィックス：" + }, + { + "indent": 12, + "text": "tpm", + "ja": "TPM" + }, + { + "indent": 3, + "text": "Reference:", + "ja": "参照：" + }, + { + "indent": 12, + "text": "draft-ietf-rats-yang-tpm-charra (RFC form)", + "ja": "ドラフト-ITETF-RATS-YANG-TPM-CHARRA（RFCフォーム）" + }, + { + "indent": 3, + "text": "Name:", + "ja": "名前：" + }, + { + "indent": 12, + "text": "ietf-tcg-algs", + "ja": "IETF-TCG-ALGS" + }, + { + "indent": 3, + "text": "Namespace:", + "ja": "名前空間：" + }, + { + "indent": 12, + "text": "urn:ietf:params:xml:ns:yang:ietf-tcg-algs", + "ja": "urn：ietf：params：xml：ns：yang：ietf-tcg-algs" + }, + { + "indent": 3, + "text": "Prefix:", + "ja": "プレフィックス：" + }, + { + "indent": 12, + "text": "taa", + "ja": "タア" + }, + { + "indent": 3, + "text": "Reference:", + "ja": "参照：" + }, + { + "indent": 12, + "text": "draft-ietf-rats-yang-tpm-charra (RFC form)", + "ja": "ドラフト-ITETF-RATS-YANG-TPM-CHARRA（RFCフォーム）" + }, + { + "indent": 0, + "text": "4. Security Considerations", + "section_title": true, + "ja": "4. セキュリティに関する考慮事項" + }, + { + "indent": 3, + "text": "The YANG module ietf-tpm-remote-attestation.yang specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446].", + "ja": "このドキュメントで指定されたYangモジュールIETF-TPM-Remote-Attestation.Yangは、NetConf [RFC6241]やRestConf [RFC8040]などのネットワーク管理プロトコルを介してアクセスするように設計されたデータのスキーマを定義しています。最低のネットコン層は安全な輸送層であり、実装から実装の安全な輸送は安全なシェル（SSH）[RFC6242]です。最も低いRESTCONF層はHTTPSであり、実装対象の安全な輸送はTLS [RFC8446]です。" + }, + { + "indent": 3, + "text": "The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.", + "ja": "ネットワーク構成アクセス制御モデル（NACM）[RFC8341]は、利用可能なすべてのNetConfまたはRestConfプロトコル操作とコンテンツの事前に構成されたサブセットに特定のNetConfまたはRestConfユーザーのアクセスを制限する手段を提供します。" + }, + { + "indent": 3, + "text": "Of special consideration are the following nodes:", + "ja": "特別な考慮事項は次のノードです。" + }, + { + "indent": 6, + "text": "* In the 'tpms' container, the 'certificates' will expose certificates used for attestation, potentially allowing selection of a certificate that might be compromised. The 'type' could also be misconfigured to represent a different type of key, which might alter how a Verifier might evaluate the results.", + "ja": "* 「TPMS」コンテナでは、「証明書」は証明に使用される証明書を公開し、侵害される可能性のある証明書の選択を可能にする可能性があります。「タイプ」は、異なるタイプのキーを表すために誤解される可能性があり、検証者が結果を評価する方法を変える可能性があります。" + }, + { + "indent": 6, + "text": "* Within the 'attester-supported-algos' container, each leaf-list will expose and potentially allow changing of the encryption algorithms supported by a device.", + "ja": "* 「Astester-Supported-Algos」コンテナ内では、各リーフリストが露出し、デバイスでサポートされている暗号化アルゴリズムの変更を可能にします。" + }, + { + "indent": 3, + "text": "There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., _config true_, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., _edit-config_) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes as well as their sensitivity/vulnerability:", + "ja": "このYangモジュールには、作成可能/クリエーション/削除可能な（つまり、デフォルトである_config true_）と定義されている多くのデータノードがあります。これらのデータノードは、一部のネットワーク環境で敏感または脆弱と見なされる場合があります。適切な保護なしにこれらのデータノードに操作を書き込む（_edit-config_）は、ネットワーク操作に悪影響を与える可能性があります。これらは、サブツリーとデータノード、および感度/脆弱性です。" + }, + { + "indent": 3, + "text": "Container '/rats-support-structures/attester-supported-algos':", + "ja": "Container '/rats-support-structures/Attester-supported-algos'：" + }, + { + "indent": 12, + "text": "'tpm1 2-asymmetric-signing', 'tpm12-hash', 'tpm20-asymmetric-signing', and 'tpm20-hash'. All could be populated with algorithms that are not supported by the underlying physical TPM installed by the equipment vendor. A vendor should restrict the ability to configure unsupported algorithms.", + "ja": "'TPM1 2-ASYMMETRIC-SIGNING'、「TPM12-HASH」、「TPM20-ASYMMETRIC-SIGINA」、および「TPM20-HASH」。すべては、機器ベンダーによってインストールされている基礎となる物理TPMによってサポートされていないアルゴリズムを入力できます。ベンダーは、サポートされていないアルゴリズムを構成する機能を制限する必要があります。" + }, + { + "indent": 3, + "text": "Container: '/rats-support-structures/tpms':", + "ja": "コンテナ： '/rats-support-structures/tpms'：" + }, + { + "indent": 12, + "text": "'name': Although shown as 'rw', it is system generated. Therefore, it should not be possible for an operator to add or remove a TPM from the configuration.", + "ja": "「名前」：「RW」として表示されていますが、システムが生成します。したがって、オペレーターが構成からTPMを追加または削除することはできないはずです。" + }, + { + "indent": 12, + "text": "'tpm20-pcr-bank': It is possible to configure PCRs that are not being extended by system software for extraction. This could unnecessarily use TPM resources.", + "ja": "「TPM20-PCR-BANK」：抽出用のシステムソフトウェアによって拡張されていないPCRを構成することができます。これにより、TPMリソースを不必要に使用できます。" + }, + { + "indent": 12, + "text": "'certificates': It is possible to provision a certificate that does not correspond to an AIK within the TPM 1.2, or to an Attestation Key (AK) within the TPM 2.0, respectively. In such a case, calls to an RPC requesting this specific certificate could result in either no response or a response from an unexpected TPM.", + "ja": "「証明書」：TPM 1.2内のAIKに対応しない証明書を、それぞれTPM 2.0内の証明キー（AK）に提供することができます。そのような場合、この特定の証明書を要求するRPCへの呼び出しは、予期しないTPMからの応答や応答のいずれかをもたらす可能性があります。" + }, + { + "indent": 3, + "text": "RPC 'tpm12-challenge-response-attestation':", + "ja": "RPC 'TPM12-Challenge-Response-Attestation'：" + }, + { + "indent": 12, + "text": "The receiver of the RPC response must verify that the certificate is for an active AIK, i.e., the certificate has been confirmed by a third party as being able to support Attestation on the targeted TPM 1.2.", + "ja": "RPC応答の受信者は、証明書がアクティブなAIK用であることを確認する必要があります。つまり、証明書は、ターゲットを絞ったTPM 1.2の証明をサポートできるとサードパーティによって確認されています。" + }, + { + "indent": 3, + "text": "RPC 'tpm20-challenge-response-attestation':", + "ja": "RPC 'TPM20-Challenge-Response-Attestation'：" + }, + { + "indent": 12, + "text": "The receiver of the RPC response must verify that the certificate is for an active AK, i.e., the private key confirmation of the quote signature within the RPC response has been confirmed by a third party to belong to an entity legitimately able to perform Attestation on the targeted TPM 2.0.", + "ja": "RPC応答の受信者は、証明書がアクティブなAK用であることを確認する必要があります。つまり、RPC応答内の引用署名の秘密の確認は、第三者によって、正当な証明を実行できるエンティティに属することが確認されています。ターゲットTPM 2.0。" + }, + { + "indent": 3, + "text": "RPC 'log-retrieval':", + "ja": "rpc 'log-retrieval'：" + }, + { + "indent": 12, + "text": "Requesting a large volume of logs from the Attester could require significant system resources and create a denial of service.", + "ja": "Attesterから大量のログを要求すると、重要なシステムリソースが必要になり、サービスの拒否が必要になる場合があります。" + }, + { + "indent": 3, + "text": "Information collected through the RPCs above could reveal specific versions of software and configurations of endpoints that could identify vulnerabilities on those systems. Therefore, RPCs should be protected by NACM [RFC8341] with a default setting of deny-all to limit the extraction of attestation data by only authorized Verifiers.", + "ja": "上記のRPCを介して収集された情報は、これらのシステムの脆弱性を特定できるエンドポイントのソフトウェアと構成の特定のバージョンを明らかにする可能性があります。したがって、RPCは、deny-allのデフォルト設定でNACM [RFC8341]によって保護され、認証された検証剤のみによって証明データの抽出を制限する必要があります。" + }, + { + "indent": 3, + "text": "For the YANG module ietf-tcg-algs.yang, please use care when selecting specific algorithms. The introductory section of [TCG-Algos] highlights that some algorithms should be considered legacy, and recommends implementers and adopters diligently evaluate available information such as governmental, industrial, and academic research before selecting an algorithm for use.", + "ja": "YangモジュールIETF-TCG-ALGS.YANGについては、特定のアルゴリズムを選択する際には注意してください。[TCG-Algos]の紹介セクションは、いくつかのアルゴリズムをレガシーと見なすべきであることを強調し、使用するアルゴリズムを選択する前に、政府、産業、学術研究などの利用可能な情報を実装者と採用者に熱心に評価することを推奨しています。" + }, + { + "indent": 3, + "text": "Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability:", + "ja": "このYangモジュールの読み取り可能なデータノードの一部は、一部のネットワーク環境で敏感または脆弱と見なされる場合があります。したがって、これらのデータノードへの読み取りアクセス（GET、GetConfig、または通知を介して）を制御することが重要です。これらは、サブツリーとデータノードとその感度/脆弱性です。" + }, + { + "indent": 3, + "text": "Event logs (bios-log, ima-log, netequip-boot-log) typically contain hash values (digests) of running boot and OS software. Passive attackers can use these hash values to identify software versions and thus launch targeted attacks on known vulnerabilities. Hence, bios-log, ima-log, and netequip-boot-log are considered sensitive.", + "ja": "イベントログ（BIOS-LOG、IMA-LOG、NetEquip-Boot-Log）には、通常、実行中のブートソフトウェアのハッシュ値（ダイジェスト）が含まれています。受動的な攻撃者は、これらのハッシュ値を使用してソフトウェアバージョンを識別し、既知の脆弱性に対する標的攻撃を開始できます。したがって、BIOS-LOG、IMA-LOG、およびNet Equip-Boot-Logは敏感であると見なされます。" + }, + { + "indent": 3, + "text": "Some of the RPC operations in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control access to these operations. These are the operations and their sensitivity/vulnerability:", + "ja": "このヤンモジュールのRPC操作の一部は、一部のネットワーク環境で敏感または脆弱と見なされる場合があります。したがって、これらの操作へのアクセスを制御することが重要です。これらは、操作とその感度/脆弱性です。" + }, + { + "indent": 3, + "text": "The 'log-retrieval' RPC operation is considered sensitive since it enables retrieval of logs (bios-log, ima-log, netequip-boot-log) that typically contain hash values (digests) of running boot and OS software. This allows specifics of loaded software including BIOS and operating system software to be understood externally.", + "ja": "「log-retrieval」RPC操作は、通常、ランニングブートおよびOSソフトウェアのハッシュ値（ダイジェスト）を含むログ（BIOS-LOG、IMA-LOG、NET-Equip-Boot-Log）の取得を可能にするため、感度が高いと見なされます。これにより、BIOSやオペレーティングシステムソフトウェアを含むロードされたソフトウェアの詳細を外部で理解できます。" + }, + { + "indent": 3, + "text": "The other two RPC operations, 'tpm20-challenge-response-attestation' and 'tpm12-challenge-response-attestation', will expose values indicating the internal operational state of the device. These values could also be correlated to specifics of running software as well.", + "ja": "他の2つのRPC操作「TPM20-Challenge-Response-Attestation」と「TPM12-Challenge-Response-Attestation」は、デバイスの内部動作状態を示す値を公開します。これらの値は、ランニングソフトウェアの詳細とも相関する可能性があります。" + }, + { + "indent": 0, + "text": "5. References", + "section_title": true, + "ja": "5. 参考文献" + }, + { + "indent": 0, + "text": "5.1. Normative References", + "section_title": true, + "ja": "5.1. 引用文献" + }, + { + "indent": 3, + "text": "[BIOS-Log] Trusted Computing Group, \"TCG PC Client Platform Firmware\n Profile Specification\", Family \"2.0\" Level 00 Revision\n 1.03 Version 51, 1 May 2017,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[CEL] Trusted Computing Group, \"Canonical Event Log Format\",\n Version 1.0 Revision 0.41, 25 February 2022,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[IEEE-Std-1363-2000]\n IEEE, \"IEEE Standard Specifications for Public-Key\n Cryptography\", IEEE Std 1363-2000,\n DOI 10.1109/IEEESTD.2000.92292, August 2000,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[IEEE-Std-1363a-2004]\n IEEE, \"IEEE Standard Specifications for Public-Key\n Cryptography - Amendment 1: Additional Techniques\", IEEE\n Std 1363a-2004, DOI 10.1109/IEEESTD.2004.94612, September\n 2004, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[ISO-IEC-10116]\n ISO/IEC, \"Information technology - Security techniques -\n Modes of operation for an n-bit block cipher\", Edition 4,\n ISO/IEC 10116:2017, July 2017,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[ISO-IEC-10118-3]\n ISO/IEC, \"IT Security techniques - Hash-functions - Part\n 3: Dedicated hash-functions\", Edition 4, ISO/\n IEC 10118-3:2018, October 2018,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[ISO-IEC-14888-3]\n ISO/IEC, \"Security techniques - Digital signatures with\n appendix - Part 3: Discrete logarithm based mechanisms\",\n Edition 4, ISO/IEC 14888-3:2018, November 2018,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[ISO-IEC-15946-1]\n ISO/IEC, \"Information technology - Security techniques -\n Cryptographic techniques based on elliptic curves - Part\n 1: General\", Edition 3, ISO/IEC 15946-1:2016, July 2016,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[ISO-IEC-18033-3]\n ISO/IEC, \"Information technology - Security techniques -\n Encryption algorithms - Part 3: Block ciphers\", Edition 2,\n ISO/IEC 18033-3:2010, December 2010,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[ISO-IEC-9797-1]\n ISO/IEC, \"Information technology - Security techniques -\n Message Authentication Codes (MACs) - Part 1: Mechanisms\n using a block cipher\", Edition 2, ISO/IEC 9797-1:2011,\n November 2011, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[ISO-IEC-9797-2]\n ISO/IEC, \"Information security - Message authentication\n codes (MACs) - Part 2: Mechanisms using a dedicated hash-\n function\", Edition 3, ISO/IEC 9797-2:2021, June 2021,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[NIST-FIPS-202]\n NIST, \"SHA-3 Standard: Permutation-Based Hash and\n Extendable-Output Functions\", NIST FIPS 202,\n DOI 10.6028/NIST.FIPS.202, August 2015,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[NIST-SP800-108]\n Chen, L., \"Recommendation for Key Derivation Using\n Pseudorandom Functions\",\n DOI 10.6028/NIST.SP.800-108r1-upd1, NIST\n SP 800-108r1-upd1, February 2024,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[NIST-SP800-38C]\n Dworkin, M., \"Recommendation for Block Cipher Modes of\n Operation: the CCM Mode for Authentication and\n Confidentiality\", NIST SP 800-38C,\n DOI 10.6028/NIST.SP.800-38C, July 2007,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[NIST-SP800-38D]\n Dworkin, M., \"Recommendation for Block Cipher Modes of\n Operation: Galois/Counter Mode (GCM) and GMAC\", NIST\n SP 800-38D, DOI 10.6028/NIST.SP.800-38D, November 2007,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[NIST-SP800-38F]\n Dworkin, M., \"Recommendation for Block Cipher Modes of\n Operation: Methods for Key Wrapping\", NIST SP 800-38F,\n DOI 10.6028/NIST.SP.800-38F, December 2012,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[NIST-SP800-56A]\n Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R.\n Davis, \"Recommendation for Pair-Wise Key-Establishment\n Schemes Using Discrete Logarithm Cryptography\", NIST\n SP 800-56A Rev. 3, DOI 10.6028/NIST.SP.800-56Ar3, April\n 2018, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, \"HMAC: Keyed-\n Hashing for Message Authentication\", RFC 2104,\n DOI 10.17487/RFC2104, February 1997,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC2119] Bradner, S., \"Key words for use in RFCs to Indicate\n Requirement Levels\", BCP 14, RFC 2119,\n DOI 10.17487/RFC2119, March 1997,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC3688] Mealling, M., \"The IETF XML Registry\", BCP 81, RFC 3688,\n DOI 10.17487/RFC3688, January 2004,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC6020] Bjorklund, M., Ed., \"YANG - A Data Modeling Language for\n the Network Configuration Protocol (NETCONF)\", RFC 6020,\n DOI 10.17487/RFC6020, October 2010,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,\n and A. Bierman, Ed., \"Network Configuration Protocol\n (NETCONF)\", RFC 6241, DOI 10.17487/RFC6241, June 2011,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC6242] Wasserman, M., \"Using the NETCONF Protocol over Secure\n Shell (SSH)\", RFC 6242, DOI 10.17487/RFC6242, June 2011,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC6933] Bierman, A., Romascanu, D., Quittek, J., and M.\n Chandramouli, \"Entity MIB (Version 4)\", RFC 6933,\n DOI 10.17487/RFC6933, May 2013,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC6991] Schoenwaelder, J., Ed., \"Common YANG Data Types\",\n RFC 6991, DOI 10.17487/RFC6991, July 2013,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,\n \"PKCS #1: RSA Cryptography Specifications Version 2.2\",\n RFC 8017, DOI 10.17487/RFC8017, November 2016,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8032] Josefsson, S. and I. Liusvaara, \"Edwards-Curve Digital\n Signature Algorithm (EdDSA)\", RFC 8032,\n DOI 10.17487/RFC8032, January 2017,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, \"RESTCONF\n Protocol\", RFC 8040, DOI 10.17487/RFC8040, January 2017,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8174] Leiba, B., \"Ambiguity of Uppercase vs Lowercase in RFC\n 2119 Key Words\", BCP 14, RFC 8174, DOI 10.17487/RFC8174,\n May 2017, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8341] Bierman, A. and M. Bjorklund, \"Network Configuration\n Access Control Model\", STD 91, RFC 8341,\n DOI 10.17487/RFC8341, March 2018,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8348] Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, \"A\n YANG Data Model for Hardware Management\", RFC 8348,\n DOI 10.17487/RFC8348, March 2018,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8446] Rescorla, E., \"The Transport Layer Security (TLS) Protocol\n Version 1.3\", RFC 8446, DOI 10.17487/RFC8446, August 2018,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and\n W. Pan, \"Remote ATtestation procedureS (RATS)\n Architecture\", RFC 9334, DOI 10.17487/RFC9334, January\n 2023, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC9642] Watsen, K., \"A YANG Data Model for a Keystore\", RFC 9642,\n DOI 10.17487/RFC9642, October 2024,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC9683] Fedorkow, G. C., Ed., Voit, E., and J. Fitzgerald-McKay,\n \"Remote Integrity Verification of Network Devices\n Containing Trusted Platform Modules\", RFC 9683,\n DOI 10.17487/RFC9683, December 2024,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[TCG-Algos]\n Trusted Computing Group, \"TCG Algorithm Registry\", Family\n \"2.0\" Level 00 Revision 01.34, 24 August 2023,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[TPM1.2] Trusted Computing Group, \"TPM 1.2 Main Specification\", TPM\n Main Specification Level 2 Version 1.2, Revision 116, 1\n March 2011, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[TPM1.2-Commands]\n Trusted Computing Group, \"TPM Main Part 3 Commands\", TPM\n Main Specification Level 2 Version 1.2, Revision 116, 1\n March 2011, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[TPM1.2-Structures]\n Trusted Computing Group, \"TPM Main Part 2 TPM Structures\",\n TPM Main Specification Level 2 Version 1.2, Revision 116,\n 1 March 2011, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[TPM2.0] Trusted Computing Group, \"TPM 2.0 Library\", Trusted\n Platform Module Library Specification, Family \"2.0\", Level\n 00, Revision 01.83, March 2024,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[TPM2.0-Arch]\n Trusted Computing Group, \"Trusted Platform Module Library\n Part 1: Architecture\", Family \"2.0\", Level 00, Revision\n 01.83, 25 January 2024,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[TPM2.0-Key]\n Trusted Computing Group, \"TPM 2.0 Keys for Device Identity\n and Attestation\", Version 1.00, Revision 12, 8 October\n 2021, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[TPM2.0-Structures]\n Trusted Computing Group, \"Trusted Platform Module Library\n Part 2: Structures\", Family \"2.0\", Level 00, Revision\n 01.83, 25 January 2024,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[UEFI-Secure-Boot]\n Unified Extensible Firmware Interface (UEFI) Forum, Inc.,\n \"Unified Extensible Firmware Interface (UEFI)\n Specification\", Section 32.1: Secure Boot, Version 2.10,\n 29 August 2022,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "5.2. Informative References", + "section_title": true, + "ja": "5.2. 参考引用" + }, + { + "indent": 3, + "text": "[IMA-Template-Management]\n The kernel development community, \"IMA Template Management\n Mechanism\", Linux Kernel 6.11, 15 September 2024,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[NIST-915121]\n NIST, \"True Randomness Can't be Left to Chance: Why\n entropy is important for information security\",\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RATS-Interaction-Models]\n Birkholz, H., Eckel, M., Pan, W., and E. Voit, \"Reference\n Interaction Models for Remote Attestation Procedures\",\n Work in Progress, Internet-Draft, draft-ietf-rats-\n reference-interaction-models-11, 22 July 2024,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[XML-Registry]\n IANA, \"IETF XML Registry\",\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[YANG-Parameters]\n IANA, \"YANG Parameters\",\n .", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "Appendix A. Integrity Measurement Architecture (IMA)", + "section_title": true, + "ja": "付録A. 整合性測定アーキテクチャ（IMA）" + }, + { + "indent": 3, + "text": "IMA extends the principles of Measured Boot [TPM2.0-Arch] and Secure Boot [UEFI-Secure-Boot] to the Linux operating system, applying it to operating system applications and files. IMA has been part of the Linux integrity subsystem of the Linux kernel since 2009 (kernel version 2.6.30). The IMA mechanism represented by the YANG module in this specification is rooted in the kernel version 5.16 [IMA-Template-Management]. IMA enables the protection of system integrity by collecting (commonly referred to as measuring) and storing measurements (called Claims in the context of IETF RATS) of files before execution so that these measurements can be used later, at system runtime, in remote attestation procedures. IMA acts in support of the Appraisal of Evidence (which includes measurement Claims) by leveraging Reference Values stored in extended file attributes.", + "ja": "IMAは、測定されたブート[TPM2.0-ARCH]およびセキュアブート[UEFI-Secure-Boot]の原理をLinuxオペレーティングシステムに拡張し、オペレーティングシステムのアプリケーションとファイルに適用します。IMAは、2009年以来、LinuxカーネルのLinux Integrityサブシステムの一部です（Kernelバージョン2.6.30）。この仕様でYangモジュールで表されるIMAメカニズムは、カーネルバージョン5.16 [IMA-Template-Management]に根ざしています。IMAは、実行前にファイルのファイルの測定値（IETFラットのコンテキストでクレーム）を収集し（一般に測定と呼ばれる）、保存することにより、システムの整合性の保護を可能にします。。IMAは、拡張ファイル属性に保存されている参照値を活用することにより、証拠の評価（測定クレームを含む）を支持して行動します。" + }, + { + "indent": 3, + "text": "In support of the Appraisal of Evidence, IMA maintains an ordered list (with no duplicates) of measurements in kernel space, the Stored Measurement Log (SML), for all files that have been measured before execution since the operating system was started. Although IMA can be used without a TPM, it is typically used in conjunction with a TPM to anchor the integrity of the SML in a hardware-protected secure storage location, i.e., PCRs provided by TPMs. IMA provides the SML in both binary and ASCII representations in the Linux security file system _securityfs_ (/sys/kernel/security/ima/).", + "ja": "証拠の評価を支持して、IMAは、オペレーティングシステムが開始されてから実行前に測定されたすべてのファイルに対して、保存された測定ログ（SML）であるカーネル空間での測定値（重複なし）を維持しています。IMAはTPMなしで使用できますが、通常、TPMと組み合わせて使用され、ハードウェアで保護されたセキュアストレージの場所、つまりTPMによって提供されるPCRにSMLの整合性を固定します。IMAは、Linuxセキュリティファイルシステム_SecurityFS_（/sys/kernel/security/ima/）でバイナリ表現とASCII表現の両方でSMLを提供します。" + }, + { + "indent": 3, + "text": "IMA templates define the format of the SML, i.e., which fields are included in a log record. Examples are file path, file hash, user ID, group ID, file signature, and extended file attributes. IMA comes with a set of predefined template formats and also allows a custom format, i.e., a format consisting of template fields supported by IMA. Template usage is typically determined by boot arguments passed to the kernel. Alternatively, the format can also be hard-coded into custom kernels. IMA templates and fields are extensible in the kernel source code. As a result, more template fields can be added in the future.", + "ja": "IMAテンプレートは、SMLの形式、つまりログレコードに含まれるフィールドを定義します。例は、ファイルパス、ファイルハッシュ、ユーザーID、グループID、ファイル署名、拡張ファイル属性です。IMAには、事前定義されたテンプレート形式のセットが付属しており、カスタム形式、つまりIMAがサポートするテンプレートフィールドで構成される形式も許可しています。テンプレートの使用は、通常、カーネルに渡されたブート引数によって決定されます。または、この形式をカスタムカーネルにハードコーディングすることもできます。IMAテンプレートとフィールドは、カーネルソースコードで拡張可能です。その結果、将来、より多くのテンプレートフィールドを追加できます。" + }, + { + "indent": 3, + "text": "IMA policies define which files are measured using the IMA policy language. Built-in policies can be passed as boot arguments to the kernel. Custom IMA policies can be defined once during runtime or be hard-coded into a custom kernel. If no policy is defined, no measurements are taken and IMA is effectively disabled.", + "ja": "IMAポリシーは、IMAポリシー言語を使用して測定されるファイルを定義します。組み込みのポリシーは、カーネルのブート引数として渡すことができます。カスタムIMAポリシーは、ランタイム中に1回定義することも、カスタムカーネルにハードコーディングすることもできます。ポリシーが定義されていない場合、測定は行われず、IMAは効果的に無効になります。" + }, + { + "indent": 3, + "text": "A comprehensive description of the content fields of the Linux IMA TLV format can be found in Table 16 of the Canonical Event Log (CEL) specification [CEL]. The CEL specification also illustrates the use of templates to enable extended or customized IMA TLV formats in Section 5.1.6.", + "ja": "Linux IMA TLV形式のコンテンツフィールドの包括的な説明は、標準イベントログ（CEL）の表16の表16にあります。CEL仕様は、セクション5.1.6で拡張またはカスタマイズされたIMA TLV形式を有効にするためのテンプレートの使用も示しています。" + }, + { + "indent": 0, + "text": "Appendix B. IMA for Network Equipment Boot Logs", + "section_title": true, + "ja": "付録B. ネットワーク機器のブートログ用のIMA" + }, + { + "indent": 3, + "text": "Network equipment can generally implement similar IMA-protected functions to generate measurements (Claims) about the boot process of a device and enable corresponding remote attestation. Network Equipment Boot Logs combine the measurement and logging of boot components and operating system components (executables and files) into a single log file in a format identical to the IMA format. Note that the format used for logging measurement of boot components in this scheme differs from the boot logging strategy described elsewhere in this document.", + "ja": "ネットワーク機器は一般に、同様のIMA保護機能を実装して、デバイスのブートプロセスに関する測定（クレーム）を生成し、対応するリモートの証明を有効にすることができます。ネットワーク機器ブートログは、ブートコンポーネントとオペレーティングシステムコンポーネント（実行可能ファイルとファイル）の測定とロギングを、IMA形式と同一の形式で単一のログファイルに組み合わせます。このスキームのブートコンポーネントのロギング測定に使用される形式は、このドキュメントの他の場所で説明されているブートロギング戦略とは異なることに注意してください。" + }, + { + "indent": 3, + "text": "During the boot process of the network device, i.e., from BIOS to the end of the operating system and user-space, all files executed can be measured and logged in the order of their execution. When the Verifier initiates a remote attestation process (e.g., challenge-response remote attestation as defined in this document), the network equipment takes on the role of an Attester and can convey to the Verifier Claims that comprise the measurement log as well as the corresponding PCR values (Evidence) of a TPM.", + "ja": "ネットワークデバイスのブートプロセス、つまり、BIOSからオペレーティングシステムとユーザースペースの終わりまで、実行されたすべてのファイルを測定して実行することができます。検証者がリモートの証明プロセス（このドキュメントで定義されているチャレンジ応答リモートの証明）を開始すると、ネットワーク機器はアテスターの役割を引き受け、対応する測定ログと測定ログを構成する検証者に伝えることができますTPMのPCR値（証拠）。" + }, + { + "indent": 3, + "text": "The Verifier can appraise the integrity (compliance with the Reference Values) of each executed file by comparing its measured value with the Reference Value. Based on the execution order, the Verifier can compute a PCR Reference Value (by replaying the log) and compare it to the measurement log Claims obtained in conjunction with the PCR Evidence to assess their trustworthiness with respect to an intended operational state.", + "ja": "検証者は、測定値を参照値と比較することにより、実行された各ファイルの整合性（参照値のコンプライアンス）を評価できます。実行順序に基づいて、検証者は（ログを再生することにより）PCR参照値を計算し、PCRの証拠と併せて得られた測定ログクレームと比較して、意図した運用状態に関する信頼性を評価します。" + }, + { + "indent": 3, + "text": "Network equipment usually executes multiple components in parallel. This holds not only during the operating system loading phase, but also even during the BIOS boot phase. With this measurement log mechanism, network equipment can assume the role of an Attester, proving to the Verifier the trustworthiness of its boot process. Using the measurement log, Verifiers can precisely identify mismatching log entries to infer potentially tampered components.", + "ja": "ネットワーク機器は通常、複数のコンポーネントを並行して実行します。これは、オペレーティングシステムの読み込み段階だけでなく、BIOSブートフェーズでも保持されます。この測定ログメカニズムにより、ネットワーク機器は、ブートプロセスの信頼性を検証剤に証明し、攻撃者の役割を引き受けることができます。測定ログを使用すると、検証剤はログエントリの不一致を正確に識別して、潜在的に改ざんされたコンポーネントを推測できます。" + }, + { + "indent": 3, + "text": "This mechanism also supports scenarios that modify files on the Attester that are subsequently executed during the boot phase (e.g., updating/patching) by simply updating the appropriate Reference Values in Reference Integrity Manifests that inform Verifiers about how an Attester is composed.", + "ja": "このメカニズムは、アテスター上のファイルを変更するシナリオもサポートしています。これは、ブートフェーズ中に実行される（たとえば、更新/パッチング）、参照整合性の適切な参照値を更新するだけで、検証者に攻撃者がどのように構成されているかを確認するだけです。" + }, + { + "indent": 0, + "text": "Authors' Addresses", + "section_title": true, + "ja": "著者のアドレス" + }, + { + "indent": 3, + "text": "Henk Birkholz\nFraunhofer SIT | ATHENE Center\nRheinstrasse 75\n64295 Darmstadt\nGermany\nEmail: henk.birkholz@ietf.contact", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Michael Eckel\nFraunhofer SIT | ATHENE Center\nRheinstrasse 75\n64295 Darmstadt\nGermany\nEmail: michael.eckel@sit.fraunhofer.de", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Shwetha Bhandari\nThoughtSpot\nEmail: shwetha.bhandari@thoughtspot.com", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Eric Voit\nCisco Systems\nEmail: evoit@cisco.com", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Bill Sulzen\nCisco Systems\nEmail: bsulzen@cisco.com", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Liang Xia (Frank)\nHuawei Technologies\nYuhuatai District\n101 Software Avenue\nNanjing\nJiangsu, 210012\nChina\nEmail: Frank.Xialiang@huawei.com", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Tom Laffey\nHewlett Packard Enterprise\nEmail: tom.laffey@hpe.com", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Guy C. Fedorkow\nJuniper Networks\n10 Technology Park Drive\nWestford, Massachusetts 01886\nUnited States of America\nEmail: gfedorkow@juniper.net", + "raw": true, + "ja": "" + } + ] +} \ No newline at end of file diff --git a/data/9000/rfc9686-trans.json b/data/9000/rfc9686-trans.json new file mode 100644 index 000000000..b87355f13 --- /dev/null +++ b/data/9000/rfc9686-trans.json @@ -0,0 +1,997 @@ +{ + "title": { + "text": "RFC 9686 - Registering Self-Generated IPv6 Addresses Using DHCPv6", + "ja": "RFC 9686 - DHCPV6を使用して、自己生成IPv6アドレスを登録します" + }, + "number": 9686, + "created_at": "2024-12-10 23:24:05.969193+09:00", + "updated_by": "", + "contents": [ + { + "indent": 0, + "text": "Internet Engineering Task Force (IETF) W. Kumari\nRequest for Comments: 9686 Google, LLC\nCategory: Standards Track S. Krishnan\nISSN: 2070-1721 Cisco Systems, Inc.\n R. Asati\n Independent\n L. Colitti\n J. Linkova\n Google, LLC\n S. Jiang\n BUPT\n December 2024", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "Registering Self-Generated IPv6 Addresses Using DHCPv6", + "section_title": true, + "ja": "DHCPV6を使用して、自己生成IPv6アドレスを登録します" + }, + { + "indent": 0, + "text": "Abstract", + "section_title": true, + "ja": "概要" + }, + { + "indent": 3, + "text": "This document defines a method to inform a DHCPv6 server that a device has one or more self-generated or statically configured addresses.", + "ja": "このドキュメントでは、DHCPV6サーバーに、デバイスに1つ以上の自己生成または静的に構成されたアドレスがあることを通知する方法を定義します。" + }, + { + "indent": 0, + "text": "Status of This Memo", + "section_title": true, + "ja": "本文書の位置付け" + }, + { + "indent": 3, + "text": "This is an Internet Standards Track document.", + "ja": "これは、インターネット標準トラックドキュメントです。" + }, + { + "indent": 3, + "text": "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.", + "ja": "このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。" + }, + { + "indent": 3, + "text": "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/rfc9686.", + "ja": "このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9686で取得できます。" + }, + { + "indent": 0, + "text": "Copyright Notice", + "section_title": true, + "ja": "著作権表示" + }, + { + "indent": 3, + "text": "Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.", + "ja": "著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。" + }, + { + "indent": 3, + "text": "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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.", + "ja": "このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。" + }, + { + "indent": 0, + "text": "Table of Contents", + "section_title": true, + "ja": "目次" + }, + { + "indent": 3, + "text": "1. Introduction\n2. Conventions and Definitions\n3. Registration Mechanism Overview\n4. DHCPv6 Address Registration Procedure\n 4.1. DHCPv6 Address Registration Option\n 4.2. DHCPv6 Address Registration Request Message\n 4.2.1. Server Message Processing\n 4.3. DHCPv6 Address Registration Acknowledgement\n 4.4. Signaling Address Registration Support\n 4.5. Retransmission\n 4.6. Registration Expiry and Refresh\n 4.6.1. SLAAC Addresses\n 4.6.2. Statically Assigned Addresses\n 4.6.3. Transmitting Refreshes\n5. Client Configuration\n6. Security Considerations\n7. Privacy Considerations\n8. IANA Considerations\n9. References\n 9.1. Normative References\n 9.2. Informative References\nAcknowledgements\nContributors\nAuthors' Addresses", + "raw": true, + "toc": true, + "ja": "" + }, + { + "indent": 0, + "text": "1. Introduction", + "section_title": true, + "ja": "1. はじめに" + }, + { + "indent": 3, + "text": "It is very common operational practice, especially in enterprise networks, to use IPv4 DHCP logs for troubleshooting or forensics purposes. An example of this includes a help desk dealing with a ticket such as \"The CEO's laptop cannot connect to the printer\"; if the Media Access Control (MAC) address of the printer is known (for example, from an inventory system), the printer's IPv4 address can be retrieved from the DHCP log or lease table and the printer can be pinged to determine if it is reachable. Another common example is a security operations team discovering suspicious events in outbound firewall logs and then consulting DHCP logs to determine which employee's laptop had that IPv4 address at that time so that they can quarantine it and remove the malware.", + "ja": "トラブルシューティングまたはフォレンジックの目的でIPv4 DHCPログを使用することは、特にエンタープライズネットワークで非常に一般的な運用慣行です。この例には、「CEOのラップトップはプリンターに接続できない」などのチケットを扱うヘルプデスクが含まれます。プリンターのメディアアクセス制御（MAC）アドレスが既知である場合（たとえば、インベントリシステムから）、プリンターのIPv4アドレスをDHCPログまたはリーステーブルから取得でき、プリンターをPingで到達できるかどうかを判断できます。。もう1つの一般的な例は、アウトバウンドファイアウォールログで疑わしいイベントを発見し、DHCPログに相談して、その時点でどの従業員のラップトップがそのIPv4アドレスを持っていたかを判断して、それを検疫してマルウェアを削除できるようにするセキュリティオペレーションチームです。" + }, + { + "indent": 3, + "text": "This operational practice relies on the DHCP server knowing the IP address assignments. This works quite well for IPv4 addresses, as most addresses are either assigned by DHCP [RFC2131] or statically configured by the network operator. For IPv6, however, this practice is much harder to implement, as devices often self-configure IPv6 addresses via Stateless Address Autoconfiguration (SLAAC) [RFC4862].", + "ja": "この運用慣行は、IPアドレスの割り当てを知っているDHCPサーバーに依存しています。ほとんどのアドレスはDHCP [RFC2131]によって割り当てられているか、ネットワークオペレーターによって静的に構成されているため、これはIPv4アドレスで非常にうまく機能します。ただし、IPv6の場合、このプラクティスは実装するのがはるかに困難です。これは、DevicesがStateless Address Autoconfiguration（SLAAC）[RFC4862]を介して自己構成されることが多いため、実装がはるかに困難です。" + }, + { + "indent": 3, + "text": "This document provides a mechanism for a device to inform the DHCPv6 server that the device has a self-configured IPv6 address (or has a statically configured address), and thus provides parity with IPv4 by making DHCPv6 infrastructure aware of self-assigned IPv6 addresses.", + "ja": "このドキュメントは、デバイスにDHCPV6サーバーに、デバイスに自己構成のIPv6アドレスがあること（または静的に構成されたアドレスがある）を通知するメカニズムを提供し、したがって、DHCPV6インフラストラクチャに自己割り当てされたIPv6アドレスを認識することによりIPv4のパリティを提供します。" + }, + { + "indent": 0, + "text": "2. Conventions and Definitions", + "section_title": true, + "ja": "2. 慣習と定義" + }, + { + "indent": 3, + "text": "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.", + "ja": "「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 \"not\"、 \"becommended\"、 \"becommented\"、 \"may\"、 \"optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。" + }, + { + "indent": 0, + "text": "3. Registration Mechanism Overview", + "section_title": true, + "ja": "3. 登録メカニズムの概要" + }, + { + "indent": 3, + "text": "The DHCPv6 protocol is used as the address registration protocol and a DHCPv6 server performs the role of an address registration server. This document introduces a new Address Registration (OPTION_ADDR_REG_ENABLE) option, which indicates that the server supports the registration mechanism. Before registering any addresses, the client MUST determine whether the network supports address registration. It can do this by including the Address Registration option code in the Option Request option (see Section 21.7 of [RFC8415]) of the Information-Request, Solicit, Request, Renew, or Rebind messages it sends to the server as part of the regular stateless or stateful DHCPv6 configuration process. If the server supports address registration, it includes an Address Registration option in its Advertise or Reply messages. To avoid undesired multicast traffic, if the DHCPv6 infrastructure does not support (or is not willing to receive) any address registration information, the client MUST NOT register any addresses using the mechanism in this specification. Otherwise, the client registers addresses as described below.", + "ja": "DHCPV6プロトコルはアドレス登録プロトコルとして使用され、DHCPV6サーバーはアドレス登録サーバーの役割を実行します。このドキュメントでは、新しいアドレス登録（option_addr_reg_enable）オプションを紹介します。これは、サーバーが登録メカニズムをサポートしていることを示します。アドレスを登録する前に、クライアントはネットワークがアドレス登録をサポートするかどうかを判断する必要があります。これは、情報の要求、勧誘、要求、更新、または通常の一部としてサーバーに送信するメッセージの一部の登録オプションコード（[RFC8415]のセクション21.7を参照[RFC8415]を参照）を含めることで行うことができます。ステートレスまたはステートフルなDHCPV6構成プロセス。サーバーがアドレス登録をサポートしている場合、アドレス登録オプションが広告または返信メッセージに含まれています。望ましくないマルチキャストトラフィックを避けるために、DHCPV6インフラストラクチャがアドレス登録情報をサポートしていない（または受け取る意思がない）場合、クライアントはこの仕様のメカニズムを使用してアドレスを登録してはなりません。それ以外の場合、クライアントは以下に説明するようにアドレスを登録します。" + }, + { + "indent": 3, + "text": "After successfully assigning a self-generated or statically configured valid IPv6 address [RFC4862] on one of its interfaces, a client implementing this specification multicasts an ADDR-REG-INFORM message (see Section 4.2) in order to inform the DHCPv6 server that this self-generated address is in use. Each ADDR-REG-INFORM message contains a DHCPv6 Identity Association (IA) Address option [RFC8415] to specify the address being registered.", + "ja": "自己生成または静的に構成された有効なIPv6アドレス[RFC4862]をそのインターフェイスの1つに割り当てた後、この仕様を実装するクライアントは、DHCPV6サーバーにこの自己を通知するために、AddR-Reg-Informメッセージ（セクション4.2を参照）を実装します（セクション4.2を参照）- 生成されたアドレスが使用されています。各addr-reg-informメッセージには、登録されているアドレスを指定するために、DHCPV6アイデンティティアソシエーション（IA）アドレスオプション[RFC8415]が含まれています。" + }, + { + "indent": 3, + "text": "The address registration mechanism overview is shown in Figure 1.", + "ja": "アドレス登録メカニズムの概要を図1に示します。" + }, + { + "indent": 3, + "text": "+--------+ +------------------+ +---------------+\n| CLIENT | | FIRST-HOP ROUTER | | DHCPv6 SERVER |\n+--------+ +---------+--------+ +-------+-------+\n | SLAAC | |\n |<--------------------> | |\n | | |\n | |\n | src: link-local address |\n | --------------------------------------------> |\n | INFORMATION-REQUEST or SOLICIT/... |\n | - OPTION REQUEST OPTION |\n | -- OPTION_ADDR_REG_ENABLE |\n | |\n | ... |\n | |\n | |\n |<--------------------------------------------- |\n | REPLY or ADVERTISE MESSAGE |\n | - OPTION_ADDR_REG_ENABLE |\n | |\n | |\n | src: address being registered |\n | --------------------------------------------> |\n | ADDR-REG-INFORM MESSAGE |Register/\n | |log addresses\n | |\n | |\n | <-------------------------------------------- |\n | ADDR-REG-REPLY MESSAGE |\n | |", + "raw": true, + "ja": "" + }, + { + "indent": 13, + "text": "Figure 1: Address Registration Procedure Overview", + "ja": "図1：アドレス登録手順の概要" + }, + { + "indent": 0, + "text": "4. DHCPv6 Address Registration Procedure", + "section_title": true, + "ja": "4. DHCPV6アドレス登録手順" + }, + { + "indent": 0, + "text": "4.1. DHCPv6 Address Registration Option", + "section_title": true, + "ja": "4.1. DHCPV6アドレス登録オプション" + }, + { + "indent": 3, + "text": "The Address Registration option (OPTION_ADDR_REG_ENABLE) indicates that the server supports the mechanism described in this document. The format of the Address Registration option is described as follows:", + "ja": "アドレス登録オプション（option_addr_reg_enable）は、サーバーがこのドキュメントで説明されているメカニズムをサポートしていることを示します。アドレス登録オプションの形式は次のように説明されています。" + }, + { + "indent": 4, + "text": " 0 1 2 3\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\n+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n| option-code | option-len |\n+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+", + "raw": true, + "ja": "" + }, + { + "indent": 16, + "text": "Figure 2: DHCPv6 Address Registration Option", + "ja": "図2：DHCPV6アドレス登録オプション" + }, + { + "indent": 3, + "text": "option-code:", + "ja": "オプションコード：" + }, + { + "indent": 12, + "text": "OPTION_ADDR_REG_ENABLE (148)", + "ja": "option_addr_reg_enable（148）" + }, + { + "indent": 3, + "text": "option-len:", + "ja": "オプションレン：" + }, + { + "indent": 12, + "text": "0", + "ja": "0" + }, + { + "indent": 3, + "text": "If a client has the address registration mechanism enabled, it MUST include this option in all Option Request options that it sends.", + "ja": "クライアントがアドレス登録メカニズムを有効にしている場合、送信するすべてのオプション要求オプションにこのオプションを含める必要があります。" + }, + { + "indent": 3, + "text": "A server that is configured to support the address registration mechanism MUST include this option in Advertise and Reply messages if the client message it is replying to contained this option in the Option Request option.", + "ja": "アドレス登録メカニズムをサポートするように構成されているサーバーは、このオプションをAdvertiseメッセージに含める必要があります。" + }, + { + "indent": 0, + "text": "4.2. DHCPv6 Address Registration Request Message", + "section_title": true, + "ja": "4.2. DHCPV6アドレス登録リクエストメッセージ" + }, + { + "indent": 3, + "text": "The DHCPv6 client sends an ADDR-REG-INFORM message to inform that an IPv6 address is assigned to the client's interface. The format of the ADDR-REG-INFORM message is described as follows:", + "ja": "DHCPV6クライアントは、IPv6アドレスがクライアントのインターフェイスに割り当てられていることを通知するために、addr-reg-informメッセージを送信します。Addr-Reg-Informメッセージの形式は、次のように説明されています。" + }, + { + "indent": 4, + "text": " 0 1 2 3\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\n+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n| msg-type | transaction-id |\n+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n| |\n. options .\n. (variable) .\n| |\n+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+", + "raw": true, + "ja": "" + }, + { + "indent": 18, + "text": "Figure 3: DHCPv6 ADDR-REG-INFORM Message", + "ja": "図3：DHCPV6 Addr-Reg-Informメッセージ" + }, + { + "indent": 3, + "text": "msg-type:", + "ja": "MSGタイプ：" + }, + { + "indent": 12, + "text": "Identifies the DHCPv6 message type; set to ADDR-REG-INFORM (36).", + "ja": "DHCPV6メッセージタイプを識別します。Addr-Reg-Inform（36）に設定します。" + }, + { + "indent": 3, + "text": "transaction-id:", + "ja": "Transaction-ID：" + }, + { + "indent": 12, + "text": "The transaction ID for this message exchange.", + "ja": "このメッセージ交換のトランザクションID。" + }, + { + "indent": 3, + "text": "options:", + "ja": "オプション：" + }, + { + "indent": 12, + "text": "The options carried in this message.", + "ja": "このメッセージに掲載されたオプション。" + }, + { + "indent": 3, + "text": "The client MUST generate a transaction ID as described in [RFC8415] and insert this value in the transaction-id field.", + "ja": "[RFC8415]で説明されているように、クライアントはトランザクションIDを生成し、この値をトランザクション-IDフィールドに挿入する必要があります。" + }, + { + "indent": 3, + "text": "The client MUST include the Client Identifier option [RFC8415] in the ADDR-REG-INFORM message.", + "ja": "クライアントは、addr-reg-informメッセージにクライアント識別子オプション[RFC8415]を含める必要があります。" + }, + { + "indent": 3, + "text": "The ADDR-REG-INFORM message MUST NOT contain the Server Identifier option and MUST contain exactly one IA Address option containing the address being registered. The valid-lifetime and preferred-lifetime fields in the option MUST match the current Valid Lifetime and Preferred Lifetime of the address being registered.", + "ja": "AddR-Reg-Informメッセージには、サーバー識別子オプションが含まれていない必要があり、登録されているアドレスを含む1つのIAアドレスオプションを正確に含める必要があります。オプション内の有効なリフェティタイムおよび優先ライフタイムフィールドは、登録されているアドレスの現在の有効な寿命と優先寿命と一致する必要があります。" + }, + { + "indent": 3, + "text": "The ADDR-REG-INFORM message is dedicated for clients to initiate an address registration request toward an address registration server. Consequently, clients MUST NOT put any Option Request option(s) in the ADDR-REG-INFORM message. Clients MAY include other options, such as the Client FQDN option [RFC4704].", + "ja": "Addr-Reg-Informメッセージは、クライアントがアドレス登録要求をアドレス登録サーバーに向けて開始するために専用です。したがって、クライアントはAddR-Reg-Informメッセージにオプションリクエストオプションを配置してはなりません。クライアントには、クライアントFQDNオプション[RFC4704]など、他のオプションが含まれる場合があります。" + }, + { + "indent": 3, + "text": "The client sends the DHCPv6 ADDR-REG-INFORM message to the All_DHCP_Relay_Agents_and_Servers multicast address (ff02::1:2). The client MUST send separate messages for each address being registered.", + "ja": "クライアントは、dhcpv6 addr-reg-informメッセージをAll_dhcp_relay_agents_and_serversマルチキャストアドレス（FF02 :: 1：2）に送信します。クライアントは、登録されているアドレスごとに個別のメッセージを送信する必要があります。" + }, + { + "indent": 3, + "text": "Unlike other types of messages, which are sent from the link-local address of the client, the ADDR-REG-INFORM message MUST be sent from the address being registered. This is primarily for \"fate sharing\" purposes; for example, if the network implements some form of Layer 2 security to prevent a client from spoofing other clients' MAC addresses, this prevents an attacker from spoofing ADDR-REG-INFORM messages.", + "ja": "クライアントのLink-Localアドレスから送信される他のタイプのメッセージとは異なり、登録されているアドレスからADDR-REG-INFOLTメッセージを送信する必要があります。これは主に「運命共有」の目的のためです。たとえば、ネットワークが何らかの形のレイヤー2セキュリティを実装して、クライアントが他のクライアントのMACアドレスを呼び起こさないようにする場合、攻撃者がAddr-Reg-Informメッセージをスプーフィングすることを防ぎます。" + }, + { + "indent": 3, + "text": "On clients with multiple interfaces, the client MUST only send the packet on the network interface that has the address being registered, even if it has multiple interfaces with different addresses. If the same address is configured on multiple interfaces, then the client MUST send the ADDR-REG-INFORM message each time the address is configured on an interface that did not previously have it and refresh each registration independently from the others.", + "ja": "複数のインターフェイスを備えたクライアントでは、クライアントは、異なるアドレスを持つ複数のインターフェイスがある場合でも、登録されているネットワークインターフェイスにパケットを送信する必要があります。同じアドレスが複数のインターフェイスで構成されている場合、アドレスが以前にそれを持っていなかったインターフェイスで構成され、他の登録を独立して各登録を更新するたびに、クライアントはAddR-Reg-Informメッセージを送信する必要があります。" + }, + { + "indent": 3, + "text": "The client MUST only send the ADDR-REG-INFORM message for valid addresses [RFC4862] of global scope [RFC4007]. This includes Unique Local Addresses (ULAs), which are defined in [RFC4193] to have global scope. This also includes statically assigned addresses of global scope (such addresses are considered to be valid indefinitely). The client MUST NOT send the ADDR-REG-INFORM message for addresses configured by DHCPv6.", + "ja": "クライアントは、グローバルスコープ[RFC4007]の有効なアドレス[RFC4862]に対してAddR-Reg-Informメッセージを送信する必要があります。これには、グローバルな範囲を持つために[RFC4193]で定義されている一意のローカルアドレス（ULAS）が含まれます。これには、グローバルスコープの静的に割り当てられたアドレスも含まれます（このようなアドレスは無期限に有効であると見なされます）。クライアントは、DHCPV6によって構成されたアドレスのADDR-REG-INFOLTメッセージを送信してはなりません。" + }, + { + "indent": 3, + "text": "The client SHOULD NOT send the ADDR-REG-INFORM message unless it has received a Router Advertisement (RA) message with either the M or O flags set to 1.", + "ja": "クライアントは、1に設定されたMまたはOフラグのいずれかを使用してルーター広告（RA）メッセージを受信しない限り、ADDR-REG-INFOLDメッセージを送信しないでください。" + }, + { + "indent": 3, + "text": "Clients MUST discard any received ADDR-REG-INFORM messages.", + "ja": "クライアントは、受信したAddR-Reg-Informメッセージを破棄する必要があります。" + }, + { + "indent": 0, + "text": "4.2.1. Server Message Processing", + "section_title": true, + "ja": "4.2.1. サーバーメッセージ処理" + }, + { + "indent": 3, + "text": "Servers MUST discard any ADDR-REG-INFORM messages that meet any of the following conditions:", + "ja": "サーバーは、次の条件のいずれかを満たすAddr-Reg-Informメッセージを破棄する必要があります。" + }, + { + "indent": 6, + "text": "* the message does not include a Client Identifier option;", + "ja": "* メッセージには、クライアント識別子オプションは含まれていません。" + }, + { + "indent": 6, + "text": "* the message includes a Server Identifier option;", + "ja": "* メッセージには、サーバー識別子オプションが含まれます。" + }, + { + "indent": 6, + "text": "* the message does not include the IA Address option, or the IP address in the IA Address option does not match the source address of the original ADDR-REG-INFORM message sent by the client. The source address of the original message is the source IP address of the packet if it is not relayed or is the peer-address field of the innermost Relay-forward message if it is relayed; or", + "ja": "* メッセージにはIAアドレスオプションが含まれていません。または、IAアドレスオプションのIPアドレスは、クライアントが送信した元のAddR-Reg-Informメッセージのソースアドレスと一致しません。元のメッセージのソースアドレスは、リレーされていない場合のパケットのソースIPアドレス、またはリレーされている場合の最も内側のリレーフォワードメッセージのピアアドレスフィールドです。または" + }, + { + "indent": 6, + "text": "* the message includes an Option Request option.", + "ja": "* メッセージには、オプションリクエストオプションが含まれています。" + }, + { + "indent": 3, + "text": "If the message is not discarded, the address registration server SHOULD verify that the address being registered is \"appropriate to the link\" as defined by [RFC8415] or within a prefix delegated to the client via DHCPv6 for Prefix Delegation (DHCPv6-PD) (see Section 6.3 of [RFC8415]). If the address being registered fails this verification, the server MUST drop the message and SHOULD log this fact. If the message passes the verification, the server:", + "ja": "メッセージが破棄されていない場合、アドレス登録サーバーは、登録されているアドレスが[RFC8415]で定義されているように「リンクに適している」、またはプレフィックス委任のためにDHCPV6を介してクライアントに委任されたプレフィックス内で「リンクに適している」ことを確認する必要があります（DHCPV6-PD）（[RFC8415]のセクション6.3を参照してください。登録されているアドレスがこの検証に失敗した場合、サーバーはメッセージをドロップする必要があり、この事実を記録する必要があります。メッセージが検証を渡す場合、サーバー：" + }, + { + "indent": 6, + "text": "* MUST log the address registration information (as is done normally for clients to which it has assigned an address), unless it is configured not to do so. The server SHOULD log the client DHCP Unique Identifier (DUID) and the link-layer address, if available. The server MAY log any other information.", + "ja": "* アドレス登録情報を記録する必要があります（アドレスを割り当てたクライアントに対して通常行われます）。サーバーは、利用可能な場合は、クライアントDHCP一意の識別子（DUID）とリンク層アドレスを記録する必要があります。サーバーは、他の情報を記録する場合があります。" + }, + { + "indent": 6, + "text": "* SHOULD register a binding between the provided Client Identifier and IPv6 address in its database, if no binding exists. The lifetime of the binding is equal to the Valid Lifetime of the address reported by the client. If there is already a binding between the registered address and the same client, the server MUST update its lifetime. If there is already a binding between the registered address and another client, the server SHOULD log the fact and update the binding.", + "ja": "* バインディングが存在しない場合は、データベースに提供されたクライアント識別子とIPv6アドレスの間にバインディングを登録する必要があります。バインディングの寿命は、クライアントが報告したアドレスの有効な寿命に等しくなります。登録されたアドレスと同じクライアントの間にすでに拘束力がある場合、サーバーはその寿命を更新する必要があります。登録アドレスと別のクライアントの間に既にバインディングがある場合、サーバーは事実を記録し、バインディングを更新する必要があります。" + }, + { + "indent": 6, + "text": "* SHOULD mark the address as unavailable for use and not include it in future Advertise messages.", + "ja": "* アドレスを使用することはできないとマークし、将来の広告メッセージに含めないでください。" + }, + { + "indent": 6, + "text": "* MUST send back an ADDR-REG-REPLY message to ensure the client does not retransmit.", + "ja": "* クライアントが再送信されないようにするために、AddR-Reg-Replyメッセージを送り返す必要があります。" + }, + { + "indent": 3, + "text": "If a client is multihomed (i.e., connected to multiple administrative domains, each operating its own DHCPv6 infrastructure), the requirement to verify that the registered address is appropriate for the link or belongs to a delegated prefix ensures that each DHCPv6 server only registers bindings for addresses from the given administrative domain.", + "ja": "クライアントがマルチホーム（つまり、複数の管理ドメインに接続され、それぞれが独自のDHCPV6インフラストラクチャに接続されている場合）の場合、登録アドレスがリンクに適しているか、委任されたプレフィックスに属していることを確認する要件は、各DHCPV6サーバーのみを保証することを保証します。指定された管理ドメインからのアドレス。" + }, + { + "indent": 3, + "text": "As mentioned in Section 4.2, although a client \"MUST NOT send the ADDR-REG-INFORM message for addresses configured by DHCPv6\", if a server does receive such a message, it SHOULD log and discard it.", + "ja": "セクション4.2で述べたように、クライアントは「DHCPV6で構成されたアドレスのADDR-REG-INFOLTメッセージを送信してはなりません」が、サーバーがそのようなメッセージを受信した場合、ログと破棄する必要があります。" + }, + { + "indent": 3, + "text": "DHCPv6 relay agents and switches that relay address registration messages directly from clients MUST include the client's link-layer address in the relayed message using the Client Link-Layer Address option [RFC6939] if they would do so for other DHCPv6 client messages such as Solicit, Request, and Rebind.", + "ja": "DHCPV6リレーエージェントとリレーアドレス登録メッセージをクライアントから直接スイッチする必要があります。クライアントリンクレイヤーアドレスオプション[RFC6939]を使用して、クライアントのリンクレイヤーアドレスをリレーしたメッセージに含める必要があります。リクエスト、そして逆にします。" + }, + { + "indent": 0, + "text": "4.3. DHCPv6 Address Registration Acknowledgement", + "section_title": true, + "ja": "4.3. DHCPV6アドレス登録承認" + }, + { + "indent": 3, + "text": "The server MUST acknowledge receipt of a valid ADDR-REG-INFORM message by sending back an ADDR-REG-REPLY message. The format of the ADDR-REG-REPLY message is described as follows:", + "ja": "サーバーは、addr-reg-replyメッセージを返送して、有効なaddr-reg-informメッセージの受信を確認する必要があります。Addr-Reg-Replyメッセージの形式は、次のように説明されています。" + }, + { + "indent": 4, + "text": " 0 1 2 3\n 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1\n+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n| msg-type | transaction-id |\n+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+\n| |\n. options .\n. (variable) .\n| |\n+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+", + "raw": true, + "ja": "" + }, + { + "indent": 18, + "text": "Figure 4: DHCPv6 ADDR-REG-REPLY Message", + "ja": "図4：DHCPV6 Addr-Reg-Replyメッセージ" + }, + { + "indent": 3, + "text": "msg-type:", + "ja": "MSGタイプ：" + }, + { + "indent": 12, + "text": "Identifies the DHCPv6 message type; set to ADDR-REG-REPLY (37).", + "ja": "DHCPV6メッセージタイプを識別します。Addr-Reg-Reply（37）に設定します。" + }, + { + "indent": 3, + "text": "transaction-id:", + "ja": "Transaction-ID：" + }, + { + "indent": 12, + "text": "The transaction ID for this message exchange.", + "ja": "このメッセージ交換のトランザクションID。" + }, + { + "indent": 3, + "text": "options:", + "ja": "オプション：" + }, + { + "indent": 12, + "text": "The options carried in this message.", + "ja": "このメッセージに掲載されたオプション。" + }, + { + "indent": 3, + "text": "If the ADDR-REG-INFORM message that the server is replying to was not relayed, then the IPv6 destination address of the message MUST be the address being registered. If the ADDR-REG-INFORM message was relayed, then the server MUST construct the Relay-reply message as specified in Section 19.3 of [RFC8415].", + "ja": "サーバーが返信しているAddR-Reg-Informメッセージが中継されていない場合、メッセージのIPv6宛先アドレスは登録されているアドレスでなければなりません。addr-reg-informメッセージがリレーされた場合、[RFC8415]のセクション19.3で指定されているように、サーバーはリレー無応メッセージを構築する必要があります。" + }, + { + "indent": 3, + "text": "The server MUST copy the transaction-id from the ADDR-REG-INFORM message to the transaction-id field of the ADDR-REG-REPLY.", + "ja": "サーバーは、Transaction-IDをADDR-REG-INFORMメッセージからAddR-Reg-ReplyのトランザクションIDフィールドにコピーする必要があります。" + }, + { + "indent": 3, + "text": "The ADDR-REG-REPLY message MUST contain an IA Address option for the address being registered. The option MUST be identical to the one in the ADDR-REG-INFORM message that the server is replying to.", + "ja": "AddR-Reg-Replyメッセージには、登録されているアドレスのIAアドレスオプションを含める必要があります。このオプションは、サーバーが返信しているAddr-Reg-Informメッセージのものと同一でなければなりません。" + }, + { + "indent": 3, + "text": "Servers MUST ignore any received ADDR-REG-REPLY messages.", + "ja": "サーバーは、受信したAddR-Reg-Replyメッセージを無視する必要があります。" + }, + { + "indent": 3, + "text": "Clients MUST discard any ADDR-REG-REPLY messages that meet any of the following conditions:", + "ja": "クライアントは、次の条件のいずれかを満たすADDR-REGREPLYメッセージを破棄する必要があります。" + }, + { + "indent": 6, + "text": "* the IPv6 destination address does not match the address being registered;", + "ja": "* IPv6宛先アドレスは、登録されているアドレスと一致しません。" + }, + { + "indent": 6, + "text": "* the IA Address option does not match the address being registered;", + "ja": "* IAアドレスオプションは、登録されているアドレスと一致しません。" + }, + { + "indent": 6, + "text": "* the address being registered is not assigned to the interface receiving the message; or", + "ja": "* 登録されているアドレスは、メッセージを受信するインターフェイスに割り当てられていません。または" + }, + { + "indent": 6, + "text": "* the transaction-id does not match the transaction-id the client used in the corresponding ADDR-REG-INFORM message.", + "ja": "* Transaction-IDは、クライアントが対応するAddR-Reg-Informメッセージで使用したトランザクションIDと一致しません。" + }, + { + "indent": 3, + "text": "The ADDR-REG-REPLY message only indicates that the ADDR-REG-INFORM message has been received and that the client should not retransmit it. The ADDR-REG-REPLY message MUST NOT be considered to be any indication of the address validity and MUST NOT be required for the address to be usable. DHCPv6 relays, or other devices that snoop ADDR-REG-REPLY messages, MUST NOT add or alter any forwarding or security state based on the ADDR-REG-REPLY message.", + "ja": "Addr-Reg-Replyメッセージは、Addr-Reg-Informメッセージが受信され、クライアントがそれを再送信してはならないことを示しています。Addr-Reg-Replyメッセージは、アドレスの有効性の兆候であると見なされてはなりません。また、アドレスを使用できるようにするには必須であってはなりません。DHCPV6リレー、またはAddR-Reg-ReplyメッセージをSnoopである他のデバイスは、AddR-Reg-Replyメッセージに基づいて転送またはセキュリティ状態を追加または変更してはなりません。" + }, + { + "indent": 0, + "text": "4.4. Signaling Address Registration Support", + "section_title": true, + "ja": "4.4. シグナリングアドレス登録サポート" + }, + { + "indent": 3, + "text": "To avoid undesired multicast traffic, the client MUST NOT register addresses using this mechanism unless the DHCPv6 infrastructure supports address registration. The client can discover this by including the OPTION_ADDR_REG_ENABLE option in the Option Request options that it sends. If the client receives and processes an Advertise or Reply message with the OPTION_ADDR_REG_ENABLE option, it concludes that the DHCPv6 infrastructure supports address registration. When the client detects address registration support, it MUST start the registration process (unless configured not to do so) and MUST immediately register any addresses that are already in use. Once the client starts the registration process, it MUST NOT stop registering addresses until it disconnects from the link, even if subsequent Advertise or Reply messages do not contain the OPTION_ADDR_REG_ENABLE option.", + "ja": "望ましくないマルチキャストトラフィックを回避するために、DHCPV6インフラストラクチャがアドレス登録をサポートしていない限り、クライアントはこのメカニズムを使用してアドレスを登録してはなりません。クライアントは、送信するオプションリクエストオプションにoption_addr_reg_enableオプションを含めることでこれを発見できます。クライアントがOption_Addr_Reg_Enableオプションを使用して広告または返信メッセージを受信および処理する場合、DHCPV6インフラストラクチャがアドレス登録をサポートしていると結論付けます。クライアントがアドレス登録サポートを検出した場合、登録プロセスを開始する必要があります（そうしないように構成されていない限り）。既に使用されているアドレスをすぐに登録する必要があります。クライアントが登録プロセスを開始したら、後続の広告または返信メッセージにoption_addr_reg_enableオプションが含まれていない場合でも、リンクから切断されるまでアドレスの登録を停止しないでください。" + }, + { + "indent": 3, + "text": "The client MUST discover whether the DHCPv6 infrastructure supports address registration every time it connects to a network or when it detects it has moved to a new link, without utilizing any prior knowledge about address registration support on that network or link. This client behavior allows networks to progressively roll out support for the Address Registration option across the DHCPv6 infrastructure without causing clients to frequently stop and restart address registration if some of the network's DHCPv6 servers support it and some do not.", + "ja": "クライアントは、DHCPV6インフラストラクチャがネットワークに接続するたびにアドレス登録をサポートしているかどうか、またはそのネットワークまたはリンクのアドレス登録サポートに関する事前知識を利用せずに、新しいリンクに移動した場合に住所登録をサポートするかどうかを発見する必要があります。このクライアントの動作により、ネットワークのDHCPV6サーバーの一部がサポートしていない場合、クライアントが頻繁に停止し、アドレス登録を再起動することなく、DHCPV6インフラストラクチャ全体のアドレス登録オプションのサポートを徐々にロールアウトできます。" + }, + { + "indent": 3, + "text": "A client with multiple interfaces MUST discover address registration support for each interface independently. The client MUST NOT send address registration messages on a given interface unless the client has discovered that the interface is connected to a network that supports address registration.", + "ja": "複数のインターフェイスを備えたクライアントは、各インターフェイスのアドレス登録サポートを個別に発見する必要があります。クライアントは、インターフェイスがアドレス登録をサポートするネットワークに接続されていることをクライアントが発見しない限り、特定のインターフェイスにアドレス登録メッセージを送信してはなりません。" + }, + { + "indent": 0, + "text": "4.5. Retransmission", + "section_title": true, + "ja": "4.5. 再送信" + }, + { + "indent": 3, + "text": "To reduce the effects of packet loss on registration, the client MUST retransmit the registration message. Retransmissions SHOULD follow the standard retransmission logic specified by Section 15 of [RFC8415] with the following default parameters for the initial retransmission time (IRT) and maximum retransmission count (MRC):", + "ja": "登録に対するパケット損失の影響を減らすために、クライアントは登録メッセージを再送信する必要があります。再送信は、[RFC8415]のセクション15で指定された標準の再送信ロジックに従って、初期再送信時間（IRT）および最大再送信数（MRC）の次のデフォルトパラメーターを使用する必要があります。" + }, + { + "indent": 6, + "text": "* IRT 1 sec", + "ja": "* IRT 1秒" + }, + { + "indent": 6, + "text": "* MRC 3", + "ja": "* MRC 3" + }, + { + "indent": 3, + "text": "The client SHOULD allow these parameters to be configured by the administrator.", + "ja": "クライアントは、これらのパラメーターを管理者によって構成することを許可する必要があります。" + }, + { + "indent": 3, + "text": "To comply with Section 16.1 of [RFC8415], the client MUST leave the transaction ID unchanged in retransmissions of an ADDR-REG-INFORM message. When the client retransmits the registration message, the lifetimes in the packet MUST be updated so that they match the current lifetimes of the address.", + "ja": "[RFC8415]のセクション16.1に準拠するには、クライアントは、AddR-Reg-Informメッセージの再送信に変更されていないままにしておく必要があります。クライアントが登録メッセージを再送信するとき、パケットの寿命を更新して、アドレスの現在の寿命と一致するようにする必要があります。" + }, + { + "indent": 3, + "text": "If an ADDR-REG-REPLY message is received for the address being registered, the client MUST stop retransmission.", + "ja": "登録されているアドレスに対してADDR-REGREPLYメッセージが受信された場合、クライアントは再送信を停止する必要があります。" + }, + { + "indent": 0, + "text": "4.6. Registration Expiry and Refresh", + "section_title": true, + "ja": "4.6. 登録の有効期限と更新" + }, + { + "indent": 3, + "text": "The client MUST refresh registrations to ensure that the server is always aware of which addresses are still valid. The client SHOULD perform refreshes as described below.", + "ja": "クライアントは、サーバーが常に有効であることをサーバーが常に認識していることを確認するために登録を更新する必要があります。クライアントは、以下に説明するようにリフレッシュを実行する必要があります。" + }, + { + "indent": 0, + "text": "4.6.1. SLAAC Addresses", + "section_title": true, + "ja": "4.6.1. SLAACアドレス" + }, + { + "indent": 3, + "text": "For an address configured using SLAAC, a function AddrRegRefreshInterval(address) is defined as 80% of the address's current Valid Lifetime. When calculating this value, the client applies a multiplier of AddrRegDesyncMultiplier to avoid synchronization with other clients, which could cause a large number of registration messages to reach the server at the same time. AddrRegDesyncMultiplier is a random value uniformly distributed between 0.9 and 1.1 (inclusive) and is chosen by the client when it starts the registration process, to ensure that refreshes for addresses with the same lifetime are coalesced (see below).", + "ja": "SLAACを使用して構成されたアドレスの場合、関数addRregrefreshinterval（アドレス）は、アドレスの現在の有効な寿命の80％として定義されます。この値を計算するとき、クライアントは他のクライアントとの同期を避けるためにAddRregdesyncMultiplierの乗数を適用します。AddRregdesyncMultiplierは、0.9から1.1（包括的）の間に均一に分布したランダムな値であり、登録プロセスを開始するときにクライアントによって選択され、同じ寿命の住所のリフレッシュが合体されていることを確認します（以下を参照）。" + }, + { + "indent": 3, + "text": "Whenever the client registers or refreshes an address, it calculates a NextAddrRegRefreshTime for that address as AddrRegRefreshInterval seconds in the future but does not schedule any refreshes.", + "ja": "クライアントがアドレスを登録またはリフレッシュするたびに、そのアドレスのnextddrregrefreshtimeを将来addRregrefreshinterval秒として計算しますが、リフレッシュをスケジュールしません。" + }, + { + "indent": 3, + "text": "Whenever the network changes the Valid Lifetime of an existing address by more than 1%, for example, by sending a Prefix Information Option (PIO) [RFC4861] with a new Valid Lifetime, the client calculates a new AddrRegRefreshInterval. The client schedules a refresh for min(now + AddrRegRefreshInterval, NextAddrRegRefreshTime). If the refresh would be scheduled in the past, then the refresh occurs immediately.", + "ja": "ネットワークが既存のアドレスの有効な寿命を1％以上変更するときはいつでも、たとえば、新しい有効な寿命でプレフィックス情報オプション（PIO）[RFC4861]を送信することにより、クライアントは新しいAddRregrefreshintervalを計算します。クライアントはMinの更新をスケジュールします（Now + AddRregrefreshinterval、NextDdrregrefreshtime）。過去に更新がスケジュールされる場合、更新はすぐに発生します。" + }, + { + "indent": 3, + "text": "Justification: This algorithm ensures that refreshes are not sent too frequently while ensuring that the server never believes that the address has expired when it has not. Specifically, after every registration:", + "ja": "正当化：このアルゴリズムは、リフレッシュがあまり頻繁に送信されないことを保証しますが、サーバーが住所がないときに期限切れになっていると信じていないことを保証します。具体的には、すべての登録の後：" + }, + { + "indent": 6, + "text": "* If the network never changes the lifetime of an address (e.g., if no further PIOs are received, or if all PIO lifetimes decrease in step with the passage of time), then no refreshes occur. Refreshes are not necessary, because the address expires at the time the server expects it to expire.", + "ja": "* ネットワークがアドレスの寿命を変更しない場合（たとえば、それ以上のPIOが受信されない場合、またはすべてのPIO寿命が時間の経過とともにステップが減少する場合）、リフレッシュは発生しません。サーバーが期限切れになると予想している時点でアドレスの有効期限が切れるため、リフレッシュは必要ありません。" + }, + { + "indent": 6, + "text": "* Any time the network changes the lifetime of an address (i.e., changes the time at which the address will expire), the client ensures that a refresh is scheduled, so that server will be informed of the new expiry.", + "ja": "* ネットワークがアドレスの寿命を変更すると（つまり、アドレスが期限切れになる時間を変更します）、クライアントは更新がスケジュールされることを保証し、サーバーに新しい有効期限を通知します。" + }, + { + "indent": 6, + "text": "* Because AddrRegDesyncMultiplier is at most 1.1, the refresh never occurs later than a point 88% between the time when the address was registered and the time when the address will expire. This allows the client to retransmit the registration for up to 12% of the original interval before it expires. This may not be possible if the network sends a Router Advertisement (RA) [RFC4861] very close to the time when the address would have expired. In this case, the client refreshes immediately, which is the best it can do.", + "ja": "* AddRregdesyncMultiplierは最大1.1であるため、住所が登録された時からアドレスが期限切れになるまでの間に、リフレッシュはポイント88％よりも遅くなることはありません。これにより、クライアントは有効期限が切れる前に元の間隔の最大12％の登録を再送信できます。これは、ネットワークがルーター広告（RA）[RFC4861]を送信して、アドレスの有効期限が切れていた場合には不可能です。この場合、クライアントはすぐにリフレッシュしますが、これはできる最善です。" + }, + { + "indent": 6, + "text": "* The 1% tolerance ensures that the client will not refresh or reschedule refreshes if the Valid Lifetime experiences minor changes due to transmission delays or clock skew between the client and the router(s) sending the RA.", + "ja": "* 1％の耐性により、有効な寿命がクライアントとルーターがRAを送信するルーターの間の伝送の遅延または時計歪みのために軽微な変更を経験した場合、クライアントが更新または再スケジュールを再スケジュールしないようにします。" + }, + { + "indent": 6, + "text": "* AddrRegRefreshCoalesce (Section 4.6.3) allows battery-powered clients to wake up less often. In particular, it allows the client to coalesce refreshes for multiple addresses formed from the same prefix, such as the stable and privacy addresses. Higher values will result in fewer wakeups but may result in more network traffic, because if a refresh is sent early, then the next RA received will cause the client to immediately send a refresh message.", + "ja": "* AddRregrefreshcoalesce（セクション4.6.3）により、バッテリー駆動のクライアントは頻繁に目を覚ますことができます。特に、クライアントは、安定したアドレスやプライバシーアドレスなど、同じプレフィックスから形成された複数のアドレスのリフレッシュを合体化できます。値が高いとウェイクアップが少なくなりますが、ネットワークトラフィックが増える可能性があります。これは、更新が早めに送信された場合、次のRAが受信するとクライアントがすぐに更新メッセージを送信するためです。" + }, + { + "indent": 6, + "text": "* In typical networks, the lifetimes in periodic RAs either contain constant values or values that decrease over time to match another lifetime, such as the lifetime of a prefix delegated to the network. In both these cases, this algorithm will refresh on the order of once per address lifetime, which is similar to the number of refreshes that are necessary using stateful DHCPv6.", + "ja": "* 典型的なネットワークでは、周期的なRAの寿命には、ネットワークに委任されたプレフィックスの寿命など、一定の寿命と一致する一定の値または値が含まれています。どちらの場合も、このアルゴリズムは、アドレスごとのライフタイムごとに1回の順序で更新されます。これは、Stateful DHCPV6を使用して必要なリフレッシュの数に似ています。" + }, + { + "indent": 6, + "text": "* Because refreshes occur at least once per address lifetime, the network administrator can control the address refresh frequency by appropriately setting the Valid Lifetime in the PIO.", + "ja": "* リフレッシュはアドレスの寿命ごとに少なくとも1回発生するため、ネットワーク管理者は、PIOで有効な寿命を適切に設定することにより、アドレスの更新周波数を制御できます。" + }, + { + "indent": 0, + "text": "4.6.2. Statically Assigned Addresses", + "section_title": true, + "ja": "4.6.2. 静的に割り当てられたアドレス" + }, + { + "indent": 3, + "text": "A statically assigned address has an infinite Valid Lifetime that is not affected by RAs. Therefore, whenever the client registers or refreshes a statically assigned address, the next refresh is scheduled for StaticAddrRegRefreshInterval seconds in the future. The default value of StaticAddrRegRefreshInterval is 4 hours. This ensures static addresses are still refreshed periodically, but refreshes for static addresses do not cause excessive multicast traffic. The StaticAddrRegRefreshInterval interval SHOULD be configurable.", + "ja": "静的に割り当てられたアドレスには、RASの影響を受けない無限の有効な寿命があります。したがって、クライアントが静的に割り当てられたアドレスを登録または更新するたびに、次の更新は将来のstaticAddrregrefreshintervalの秒にスケジュールされます。StaticAddrregrefreshintervalのデフォルト値は4時間です。これにより、静的アドレスが定期的に更新されるようになりますが、静的アドレスのリフレッシュは過度のマルチキャストトラフィックを引き起こしません。staticAddrregrefreshinterval間の間隔は構成可能である必要があります。" + }, + { + "indent": 0, + "text": "4.6.3. Transmitting Refreshes", + "section_title": true, + "ja": "4.6.3. 送信リフレッシュ" + }, + { + "indent": 3, + "text": "When a refresh is performed, the client MAY refresh all addresses assigned to the interface that are scheduled to be refreshed within the next AddrRegRefreshCoalesce seconds. The value of AddrRegRefreshCoalesce is implementation dependent, and a suggested default is 60 seconds.", + "ja": "更新が実行されると、クライアントは、次のaddRregrefreshcoalesce秒以内に更新される予定のインターフェイスに割り当てられたすべてのアドレスを更新できます。AddRregrefreshcoalesceの値は実装に依存しており、提案されたデフォルトは60秒です。" + }, + { + "indent": 3, + "text": "Registration refresh packets MUST be retransmitted using the same logic as used for initial registrations (see Section 4.5).", + "ja": "登録更新パケットは、初期登録に使用されるのと同じロジックを使用して再送信する必要があります（セクション4.5を参照）。" + }, + { + "indent": 3, + "text": "The client MUST generate a new transaction ID when refreshing the registration.", + "ja": "クライアントは、登録を更新するときに新しいトランザクションIDを生成する必要があります。" + }, + { + "indent": 3, + "text": "When a Client-Identifier-to-IPv6-address binding expires, the server MUST remove it and consider the address as available for use.", + "ja": "クライアントIdentifier-to-IPV6-Addressバインディングバインディングの有効期限が切れる場合、サーバーはそれを削除し、住所を使用できると考える必要があります。" + }, + { + "indent": 3, + "text": "The client MAY choose to notify the server when an address is no longer being used (e.g., if the client is disconnecting from the network, the address lifetime expired, or the address is being removed from the interface). To indicate that the address is not being used anymore, the client MUST set the preferred-lifetime and valid-lifetime fields of the IA Address option in the ADDR-REG-INFORM message to zero. If the server receives a message with a valid-lifetime of zero, it MUST act as if the address has expired.", + "ja": "クライアントは、アドレスが使用されなくなったときにサーバーに通知することを選択できます（たとえば、クライアントがネットワークから切断されている場合、アドレスの寿命が切れる場合、またはアドレスがインターフェイスから削除されています）。アドレスがもはや使用されていないことを示すには、クライアントは、addr-reg-informメッセージにzeroにaddr-reg-informメッセージで、IAアドレスオプションの優先標準時および有効なリフェティタイムフィールドを設定する必要があります。サーバーが有効なゼロのメッセージを受信した場合、アドレスの有効期限が切れているかのように動作する必要があります。" + }, + { + "indent": 0, + "text": "5. Client Configuration", + "section_title": true, + "ja": "5. クライアント構成" + }, + { + "indent": 3, + "text": "DHCP clients SHOULD allow the administrator to disable sending ADDR-REG-INFORM messages. Sending the messages SHOULD be enabled by default.", + "ja": "DHCPクライアントは、管理者がAddr-Reg-Informメッセージの送信を無効にすることを許可する必要があります。メッセージの送信はデフォルトで有効にする必要があります。" + }, + { + "indent": 0, + "text": "6. Security Considerations", + "section_title": true, + "ja": "6. セキュリティに関する考慮事項" + }, + { + "indent": 3, + "text": "An attacker may attempt to register a large number of addresses in quick succession in order to overwhelm the address registration server and/or fill up log files. Similar attack vectors exist today, e.g., an attacker can DoS the server with messages containing spoofed DHCP Unique Identifiers (DUIDs) [RFC8415].", + "ja": "攻撃者は、アドレス登録サーバーを圧倒したり、ログファイルを埋めるために、多数のアドレスを迅速に連続して登録しようとする場合があります。同様の攻撃ベクトルが今日存在します。たとえば、攻撃者は、スプーフィングされたDHCP一意の識別子（DUIDS）を含むメッセージを使用してサーバーをDOSすることができます[RFC8415]。" + }, + { + "indent": 3, + "text": "If a network is using First-Come, First-Served Source Address Validation Improvement (FCFS SAVI) [RFC6620], then the DHCPv6 server can trust that the ADDR-REG-INFORM message was sent by the legitimate holder of the address. This prevents a client from registering an address configured on another client.", + "ja": "ネットワークがファーストカムの最初のソースアドレス検証改善（FCFS SAVI）[RFC6620]を使用している場合、DHCPV6サーバーは、アドレスの正当な所有者によってAddR-Reg-Informメッセージが送信されたことを信頼できます。これにより、クライアントが別のクライアントで構成されたアドレスを登録することができなくなります。" + }, + { + "indent": 3, + "text": "One of the use cases for the mechanism described in this document is to identify sources of malicious traffic after the fact. Note, however, that as the device itself is responsible for informing the DHCPv6 server that it is using an address, a malicious or compromised device can simply choose to not send the ADDR-REG-INFORM message. This is an informational, optional mechanism and is designed to aid in troubleshooting and forensics. On its own, it is not intended to be a strong security access mechanism. In particular, the ADDR-REG-INFORM message MUST NOT be used for authentication and authorization purposes, because in addition to the reasons above, the packets containing the message may be dropped.", + "ja": "このドキュメントで説明されているメカニズムのユースケースの1つは、事実の後に悪意のあるトラフィックの原因を特定することです。ただし、デバイス自体がアドレスを使用していることをDHCPV6サーバーに通知する責任があるため、悪意のあるデバイスまたは侵害されたデバイスは、AddR-Reg-Informメッセージを送信しないことを選択できます。これは情報提供のオプションのメカニズムであり、トラブルシューティングとフォレンジックを支援するように設計されています。それだけでは、強力なセキュリティアクセスメカニズムになることを意図したものではありません。特に、上記の理由に加えて、メッセージを含むパケットが削除される可能性があるため、AddR-Reg-Informメッセージを認証と承認の目的に使用する必要はありません。" + }, + { + "indent": 0, + "text": "7. Privacy Considerations", + "section_title": true, + "ja": "7. プライバシーに関する考慮事項" + }, + { + "indent": 3, + "text": "If the network doesn't have Multicast Listener Discovery (MLD) snooping enabled, then IPv6 link-local multicast traffic is effectively transmitted as broadcast. In such networks, an on-link attacker listening to DHCPv6 messages might obtain information about IPv6 addresses assigned to the client. As ADDR-REG-INFORM messages contain unique identifiers such as the client's DUID, the attacker may be able to track addresses being registered and map them to the same client, even if the client uses randomized MAC addresses. This privacy consideration is not specific to the proposed mechanism. Section 4.3 of [RFC7844] discusses using the DUID for device tracking in DHCPv6 environments and provides mitigation recommendations.", + "ja": "ネットワークにマルチキャストリスナーディスカバリー（MLD）スヌーピングが有効になっていない場合、IPv6 Link-Local Multicastトラフィックは放送として効果的に送信されます。このようなネットワークでは、DHCPV6メッセージを聞くリンク攻撃者がクライアントに割り当てられたIPv6アドレスに関する情報を取得する場合があります。AddR-Reg-Informメッセージには、クライアントのDUIDなどの一意の識別子が含まれているため、攻撃者は、クライアントがランダム化されたMACアドレスを使用していても、登録されているアドレスを追跡して同じクライアントにマッピングできる場合があります。このプライバシーの考慮は、提案されたメカニズムに固有のものではありません。[RFC7844]のセクション4.3は、DHCPV6環境でのデバイス追跡にDUIDを使用して、緩和の推奨事項を提供します。" + }, + { + "indent": 3, + "text": "In general, hiding information about the specific IPv6 address from on-link observers should not be considered a security measure, as such information is usually disclosed via Duplicate Address Detection [RFC4862] to all nodes anyway, if MLD snooping is not enabled.", + "ja": "一般に、MLDスヌーピングが有効になっていない場合、とにかくすべてのノードにそのような情報が開示されるため、そのような情報は通常、そのような情報がすべてのノードに開示されるため、リンクオンオブザーバーからの特定のIPv6アドレスに関する情報を隠すことはセキュリティ尺度と見なされるべきではありません。" + }, + { + "indent": 3, + "text": "If MLD snooping is enabled, an attacker might be able to join the All_DHCP_Relay_Agents_and_Servers multicast address (ff02::1:2) group to listen for address registration messages. However, the same result can be achieved by joining the All Routers Address (ff02::2) group and listen to gratuitous neighbor advertisement messages [RFC9131]. It should be noted that this particular scenario shares the fate with DHCPv6 address assignment: if an attacker can join the All_DHCP_Relay_Agents_and_Servers multicast group, they would be able to monitor all DHCPv6 messages sent from the client to DHCPv6 servers and relays and therefore obtain the information about addresses being assigned via DHCPv6. Layer 2 isolation allows mitigating this threat by blocking on-link peer-to-peer communication between nodes.", + "ja": "MLDスヌーピングが有効になっている場合、攻撃者はALL_DHCP_RELAY_AGENTS_AND_SERVERS MULTICASTアドレス（FF02 :: 1：2）グループに参加してアドレス登録メッセージを聞くことができる場合があります。ただし、すべてのルーターアドレス（FF02 :: 2）グループに参加して、無償の近隣広告メッセージ[RFC9131]を聴くことで、同じ結果を達成できます。この特定のシナリオは、DHCPV6アドレスの割り当てと運命を共有していることに注意してください。攻撃者がALL_DHCP_RELAY_AGENTS_AND_SERVERS MULTICASTグループに参加できる場合、クライアントからDHCPV6セルバーとリレーとリレーのすべてのDHCPV6メッセージを監視し、情報を入手できます。DHCPV6を介して割り当てられているアドレス。レイヤー2の分離により、ノード間のオンリンクピアツーピア通信をブロックすることにより、この脅威を軽減できます。" + }, + { + "indent": 0, + "text": "8. IANA Considerations", + "section_title": true, + "ja": "8. IANAの考慮事項" + }, + { + "indent": 3, + "text": "This document introduces the following entities, which have been allocated in the \"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)\" registry group defined at . These include:", + "ja": "このドキュメントでは、次のエンティティを紹介します。これらのエンティティは、で定義されている「IPv6（dhcpv6）の動的ホスト構成プロトコル」レジストリグループに割り当てられています。これらには以下が含まれます：" + }, + { + "indent": 6, + "text": "* One new DHCPv6 option, described in Section 4.1, which has been allocated in the \"Option Codes\" registry:", + "ja": "* セクション4.1で説明されている1つの新しいDHCPV6オプション。「オプションコード」レジストリで割り当てられています。" + }, + { + "indent": 6, + "text": "Value:", + "ja": "値：" + }, + { + "indent": 15, + "text": "148", + "ja": "148" + }, + { + "indent": 6, + "text": "Description:", + "ja": "説明：" + }, + { + "indent": 15, + "text": "OPTION_ADDR_REG_ENABLE", + "ja": "option_addr_reg_enable" + }, + { + "indent": 6, + "text": "Client ORO:", + "ja": "クライアントORO：" + }, + { + "indent": 15, + "text": "Yes", + "ja": "はい" + }, + { + "indent": 6, + "text": "Singleton Option:", + "ja": "シングルトンオプション：" + }, + { + "indent": 15, + "text": "Yes", + "ja": "はい" + }, + { + "indent": 6, + "text": "Reference:", + "ja": "参照：" + }, + { + "indent": 15, + "text": "RFC 9686", + "ja": "RFC 9686" + }, + { + "indent": 6, + "text": "* Two new DHCPv6 messages, which have been allocated in the \"Message Types\" registry (for more information, see Sections 4.2 and 4.3, respectively, for each DHCPv6 message):", + "ja": "* 「メッセージタイプ」レジストリに割り当てられている2つの新しいDHCPV6メッセージ（詳細については、それぞれDHCPV6メッセージごとにセクション4.2と4.3を参照）を参照してください）：" + }, + { + "indent": 6, + "text": "Value:", + "ja": "値：" + }, + { + "indent": 15, + "text": "36", + "ja": "36" + }, + { + "indent": 6, + "text": "Description:", + "ja": "説明：" + }, + { + "indent": 15, + "text": "ADDR-REG-INFORM", + "ja": "addr-reg-inform" + }, + { + "indent": 6, + "text": "Reference:", + "ja": "参照：" + }, + { + "indent": 15, + "text": "RFC 9686", + "ja": "RFC 9686" + }, + { + "indent": 6, + "text": "Value:", + "ja": "値：" + }, + { + "indent": 15, + "text": "37", + "ja": "37" + }, + { + "indent": 6, + "text": "Description:", + "ja": "説明：" + }, + { + "indent": 15, + "text": "ADDR-REG-REPLY", + "ja": "Addr-Reg-Reply" + }, + { + "indent": 6, + "text": "Reference:", + "ja": "参照：" + }, + { + "indent": 15, + "text": "RFC 9686", + "ja": "RFC 9686" + }, + { + "indent": 0, + "text": "9. References", + "section_title": true, + "ja": "9. 参考文献" + }, + { + "indent": 0, + "text": "9.1. Normative References", + "section_title": true, + "ja": "9.1. 引用文献" + }, + { + "indent": 3, + "text": "[RFC2119] Bradner, S., \"Key words for use in RFCs to Indicate\n Requirement Levels\", BCP 14, RFC 2119,\n DOI 10.17487/RFC2119, March 1997,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC2131] Droms, R., \"Dynamic Host Configuration Protocol\",\n RFC 2131, DOI 10.17487/RFC2131, March 1997,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and\n B. Zill, \"IPv6 Scoped Address Architecture\", RFC 4007,\n DOI 10.17487/RFC4007, March 2005,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC4193] Hinden, R. and B. Haberman, \"Unique Local IPv6 Unicast\n Addresses\", RFC 4193, DOI 10.17487/RFC4193, October 2005,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC4704] Volz, B., \"The Dynamic Host Configuration Protocol for\n IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)\n Option\", RFC 4704, DOI 10.17487/RFC4704, October 2006,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC4862] Thomson, S., Narten, T., and T. Jinmei, \"IPv6 Stateless\n Address Autoconfiguration\", RFC 4862,\n DOI 10.17487/RFC4862, September 2007,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC6939] Halwasia, G., Bhandari, S., and W. Dec, \"Client Link-Layer\n Address Option in DHCPv6\", RFC 6939, DOI 10.17487/RFC6939,\n May 2013, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, \"Anonymity\n Profiles for DHCP Clients\", RFC 7844,\n DOI 10.17487/RFC7844, May 2016,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8174] Leiba, B., \"Ambiguity of Uppercase vs Lowercase in RFC\n 2119 Key Words\", BCP 14, RFC 8174, DOI 10.17487/RFC8174,\n May 2017, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,\n Richardson, M., Jiang, S., Lemon, T., and T. Winters,\n \"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)\",\n RFC 8415, DOI 10.17487/RFC8415, November 2018,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC9131] Linkova, J., \"Gratuitous Neighbor Discovery: Creating\n Neighbor Cache Entries on First-Hop Routers\", RFC 9131,\n DOI 10.17487/RFC9131, October 2021,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "9.2. Informative References", + "section_title": true, + "ja": "9.2. 参考引用" + }, + { + "indent": 3, + "text": "[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,\n \"Neighbor Discovery for IP version 6 (IPv6)\", RFC 4861,\n DOI 10.17487/RFC4861, September 2007,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, \"FCFS\n SAVI: First-Come, First-Served Source Address Validation\n Improvement for Locally Assigned IPv6 Addresses\",\n RFC 6620, DOI 10.17487/RFC6620, May 2012,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "Acknowledgements", + "section_title": true, + "ja": "謝辞" + }, + { + "indent": 3, + "text": "Many thanks to Bernie Volz for the significant review and feedback, as well as Hermin Anggawijaya, Carlos Jesus Bernardos, Brian Carpenter, Stuart Cheshire, Roman Danyliw, Alan DeKok, James Guichard, James Guichard, Erik Kline, Mallory Knodel, Murray Kucherawy, David Lamparter, Ted Lemon, Eric Levy-Abegnoli, Aditi Patange, Jim Reid, Michael Richardson, Patrick Rohr, John Scudder, Mark Smith, Gunter Van de Velde, Eric Vyncke, Timothy Winters, and Peter Yee for their feedback, comments, and guidance. We apologize if we inadvertently forgot to acknowledge anyone's contributions.", + "ja": "重要なレビューとフィードバック、ハーミンアンガウィジャヤ、カルロスジーザスバーナルドス、ブライアンカーペンター、スチュアートチェシャー、スチュアートチェシャー、ローマンダニリウ、アランデコック、ジェームズギチャード、ジェームズギチャード、エリッククライン、マロリーノードル、マレークエラウィー、デイビッド、デイビッドランパター、テッド・レモン、エリック・レヴィー・アベグノリ、アディティ・パターンジ、ジム・リード、マイケル・リチャードソン、パトリック・ローア、ジョン・スカダー、マーク・スミス、ガンター・ヴァン・デ・ヴェルデ、エリック・ヴィンケ、タイムシー・ウィンターズ、ピーター・イーのフィードバック、コメント、指導のためにピーター・イー。誰の貢献を認めるのを不注意に忘れてしまったことをお詫びします。" + }, + { + "indent": 0, + "text": "Contributors", + "section_title": true, + "ja": "貢献者" + }, + { + "indent": 3, + "text": "Gang Chen\nChina Mobile\n53A, Xibianmennei Ave.\nXuanwu District\nBeijing\nChina\nEmail: phdgang@gmail.com", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "Authors' Addresses", + "section_title": true, + "ja": "著者のアドレス" + }, + { + "indent": 3, + "text": "Warren Kumari\nGoogle, LLC\nEmail: warren@kumari.net", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Suresh Krishnan\nCisco Systems, Inc.\nEmail: suresh.krishnan@gmail.com", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Rajiv Asati\nIndependent\nEmail: rajiv.asati@gmail.com", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Lorenzo Colitti\nGoogle, LLC\nShibuya 3-21-3,\nJapan\nEmail: lorenzo@google.com", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Jen Linkova\nGoogle, LLC\n1 Darling Island Rd\nPyrmont 2009\nAustralia\nEmail: furry13@gmail.com", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Sheng Jiang\nBeijing University of Posts and Telecommunications\nNo. 10 Xitucheng Road\nBeijing\nHaidian District, 100083\nChina\nEmail: shengjiang@bupt.edu.cn", + "raw": true, + "ja": "" + } + ] +} \ No newline at end of file diff --git a/data/9000/rfc9689-trans.json b/data/9000/rfc9689-trans.json new file mode 100644 index 000000000..9d89adc18 --- /dev/null +++ b/data/9000/rfc9689-trans.json @@ -0,0 +1,2088 @@ +{ + "title": { + "text": "RFC 9689 - Use Cases for a PCE as a Central Controller (PCECC)", + "ja": "RFC 9689 - 中央コントローラーとしてのPCEのユースケース（PCECC）" + }, + "number": 9689, + "created_at": "2024-12-11 23:24:06.266166+09:00", + "updated_by": "", + "contents": [ + { + "indent": 0, + "text": "Internet Engineering Task Force (IETF) Z. Li\nRequest for Comments: 9689 D. Dhody\nCategory: Informational Huawei Technologies\nISSN: 2070-1721 Q. Zhao\n Etheric Networks\n K. He\n Tencent Holdings Ltd.\n B. Khasanov\n MTS Web Services (MWS)\n December 2024", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "Use Cases for a PCE as a Central Controller (PCECC)", + "section_title": true, + "ja": "中央コントローラーとしてのPCEのユースケース（PCECC）" + }, + { + "indent": 0, + "text": "Abstract", + "section_title": true, + "ja": "概要" + }, + { + "indent": 3, + "text": "The PCE is a core component of a Software-Defined Networking (SDN) system. It can be used to compute optimal paths for network traffic and update existing paths to reflect changes in the network or traffic demands. The PCE was developed to derive Traffic Engineering (TE) paths in MPLS networks, which are supplied to the headend of the paths using the Path Computation Element Communication Protocol (PCEP).", + "ja": "PCEは、ソフトウェア定義ネットワーク（SDN）システムのコアコンポーネントです。ネットワークトラフィックの最適なパスを計算し、既存のパスを更新して、ネットワークまたはトラフィックの需要の変更を反映するために使用できます。PCEは、MPLSネットワークのトラフィックエンジニアリング（TE）パスを導出するために開発されました。MPLSネットワークは、パス計算要素通信プロトコル（PCEP）を使用してパスのヘッドエンドに供給されます。" + }, + { + "indent": 3, + "text": "SDN has much broader applicability than signalled MPLS TE networks, and the PCE may be used to determine paths in a range of use cases including static Label-Switched Paths (LSPs), Segment Routing (SR), Service Function Chaining (SFC), and most forms of a routed or switched network. Therefore, it is reasonable to consider PCEP as a control protocol for use in these environments to allow the PCE to be fully enabled as a central controller.", + "ja": "SDNは、シグナル付きMPLS TEネットワークよりもはるかに広い適用性があり、PCEを使用して、静的ラベルスイッチングパス（LSP）、セグメントルーティング（SR）、サービス関数チェーン（SFC）、、および範囲のユースケースのパスを決定することができます。ルーティングまたはスイッチネットワークのほとんどの形式。したがって、PCEPをこれらの環境で使用するためのコントロールプロトコルとして考慮して、PCEを中央コントローラーとして完全に有効にすることを可能にすることが合理的です。" + }, + { + "indent": 3, + "text": "A PCE as a Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN without necessarily completely replacing it. This document describes general considerations for PCECC deployment and examines its applicability and benefits, as well as its challenges and limitations, through a number of use cases. PCEP extensions, which are required for the PCECC use cases, are covered in separate documents.", + "ja": "セントラルコントローラー（PCECC）としてのPCEは、必ずしも完全に置き換えることなく、SDNの要素とブレンドすることにより、分散コントロールプレーンの処理を簡素化できます。このドキュメントは、PCECCの展開に関する一般的な考慮事項について説明し、多くのユースケースを通じて、その適用性と利点、およびその課題と制限を調べます。PCECCユースケースに必要なPCEP拡張機能は、個別のドキュメントでカバーされています。" + }, + { + "indent": 0, + "text": "Status of This Memo", + "section_title": true, + "ja": "本文書の位置付け" + }, + { + "indent": 3, + "text": "This document is not an Internet Standards Track specification; it is published for informational purposes.", + "ja": "このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。" + }, + { + "indent": 3, + "text": "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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.", + "ja": "このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、インターネット標準のあらゆるレベルの候補者であるわけではありません。RFC 7841のセクション2を参照してください。" + }, + { + "indent": 3, + "text": "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/rfc9689.", + "ja": "このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9689で取得できます。" + }, + { + "indent": 0, + "text": "Copyright Notice", + "section_title": true, + "ja": "著作権表示" + }, + { + "indent": 3, + "text": "Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.", + "ja": "著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。" + }, + { + "indent": 3, + "text": "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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.", + "ja": "このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。" + }, + { + "indent": 0, + "text": "Table of Contents", + "section_title": true, + "ja": "目次" + }, + { + "indent": 3, + "text": "1. Introduction\n2. Terminology\n3. Use Cases\n 3.1. PCECC for Label Management\n 3.2. PCECC and SR\n 3.2.1. PCECC SID Allocation for SR-MPLS\n 3.2.2. PCECC for SR-MPLS Best Effort (BE) Paths\n 3.2.3. PCECC for SR-MPLS TE Paths\n 3.2.4. PCECC for SRv6\n 3.3. PCECC for Static TE LSPs\n 3.4. PCECC for Load Balancing (LB)\n 3.5. PCECC and Inter-AS TE\n 3.6. PCECC for Multicast LSPs\n 3.6.1. PCECC for the Setup of P2MP/MP2MP LSPs\n 3.6.2. PCECC for the End-to-End Protection of P2MP/MP2MP LSPs\n 3.6.3. PCECC for the Local Protection of P2MP/MP2MP LSPs\n 3.7. PCECC for Traffic Classification\n 3.8. PCECC for SFC\n 3.9. PCECC for Native IP\n 3.10. PCECC for BIER\n4. IANA Considerations\n5. Security Considerations\n6. References\n 6.1. Normative References\n 6.2. Informative References\nAppendix A. Other Use Cases of the PCECC\n A.1. PCECC for Network Migration\n A.2. PCECC for L3VPN and PWE3\n A.3. PCECC for Local Protection (RSVP-TE)\n A.4. Using Reliable P2MP TE-Based Multicast Delivery for\n Distributed Computations (MapReduce-Hadoop)\nAcknowledgments\nContributors\nAuthors' Addresses", + "raw": true, + "toc": true, + "ja": "" + }, + { + "indent": 0, + "text": "1. Introduction", + "section_title": true, + "ja": "1. はじめに" + }, + { + "indent": 3, + "text": "The PCE [RFC4655] was developed to offload the path computation function from routers in an MPLS Traffic Engineering (TE) network. It can compute optimal paths for traffic across a network and can also update the paths to reflect changes in the network or traffic demands. The role and function of the PCE have grown to cover several other uses (such as GMPLS [RFC7025] or Multicast) and to allow delegated stateful control [RFC8231] and PCE-initiated use of network resources [RFC8281].", + "ja": "PCE [RFC4655]は、MPLSトラフィックエンジニアリング（TE）ネットワークのルーターからパス計算関数をオフロードするために開発されました。ネットワーク間のトラフィックに最適なパスを計算でき、ネットワークまたはトラフィックの要求の変更を反映するパスを更新することもできます。PCEの役割と機能は、他のいくつかの用途（GMPLS [RFC7025]やマルチキャストなど）をカバーし、委任されたステートフルコントロール[RFC8231]およびネットワークリソースの使用[RFC8281]の委任された使用を可能にするように成長しました。" + }, + { + "indent": 3, + "text": "According to [RFC7399], Software-Defined Networking (SDN) refers to a separation between the control elements and the forwarding components so that software running in a centralized system, called a \"controller\", can act to program the devices in the network to behave in specific ways. A required element in an SDN architecture is a component that plans how the network resources will be used and how the devices will be programmed. It is possible to view this component as performing specific computations to place traffic flows within the network given knowledge of the availability of the network resources, how other forwarding devices are programmed, and the way that other flows are routed. This is the function and purpose of a PCE, and the way that a PCE integrates into a wider network control system (including an SDN system) is presented in [RFC7491].", + "ja": "[RFC7399]によると、ソフトウェア定義ネットワーク（SDN）とは、「コントローラー」と呼ばれる集中システムで実行されるソフトウェアがネットワーク内のデバイスをプログラムするように動作するように、制御要素と転送コンポーネントの分離を指します。特定の方法で動作します。SDNアーキテクチャに必要な要素は、ネットワークリソースの使用方法とデバイスのプログラム方法を計画するコンポーネントです。このコンポーネントを、ネットワークリソースの可用性、他の転送デバイスのプログラム方法、および他のフローのルーティング方法に関する知識を考慮して、ネットワーク内にトラフィックフローを配置する特定の計算を実行すると見なすことができます。これはPCEの機能と目的であり、PCEがより広いネットワーク制御システム（SDNシステムを含む）に統合する方法が[RFC7491]に表示されます。" + }, + { + "indent": 3, + "text": "[RFC8283] outlines the architecture for the PCE as a central controller, extending the framework described in [RFC4655], and demonstrates how PCEP can serve as a general southbound control protocol between the PCE and Path Computation Client (PCC). [RFC8283] further examines the motivations and applicability of PCEP as a Southbound Interface (SBI) and introduces the implications for the protocol.", + "ja": "[RFC8283]は、[RFC4655]で説明されているフレームワークを拡張し、PCEがPCEとPATH計算クライアント（PCC）の間の一般的な南行きのコントロールプロトコルとして機能する方法を示し、中央コントローラーとしてのPCEのアーキテクチャの概要を示しています。[RFC8283]は、南行きの界面（SBI）としてのPCEPの動機と適用性をさらに調べ、プロトコルへの影響を導入します。" + }, + { + "indent": 3, + "text": "[RFC9050] introduces the procedures and extensions for PCEP to support the PCECC architecture [RFC8283].", + "ja": "[RFC9050]は、PCEPアーキテクチャをサポートするためにPCEPの手順と拡張機能を導入します[RFC8283]。" + }, + { + "indent": 3, + "text": "This document describes the various use cases for the PCECC architecture.", + "ja": "このドキュメントでは、PCECCアーキテクチャのさまざまなユースケースについて説明しています。" + }, + { + "indent": 0, + "text": "2. Terminology", + "section_title": true, + "ja": "2. 用語" + }, + { + "indent": 3, + "text": "The following terminology is used in this document.", + "ja": "このドキュメントでは、次の用語が使用されています。" + }, + { + "indent": 3, + "text": "AS:", + "ja": "AS:" + }, + { + "indent": 12, + "text": "Autonomous System", + "ja": "自律システム" + }, + { + "indent": 3, + "text": "ASBR:", + "ja": "ASBR：" + }, + { + "indent": 12, + "text": "Autonomous System Border Router", + "ja": "自律システムボーダールーター" + }, + { + "indent": 3, + "text": "BGP-LS:", + "ja": "BGP-LS：" + }, + { + "indent": 12, + "text": "Border Gateway Protocol - Link State [RFC9552]", + "ja": "Border Gatewayプロトコル - リンク状態[RFC9552]" + }, + { + "indent": 3, + "text": "IGP:", + "ja": "IGP:" + }, + { + "indent": 12, + "text": "Interior Gateway Protocol (in this document, we assume IGP as either Open Shortest Path First (OSPF) [RFC2328] [RFC5340] or Intermediate System to Intermediate System (IS-IS) [RFC1195])", + "ja": "インテリアゲートウェイプロトコル（このドキュメントでは、IGPは最初に最短パスを開く（OSPF）[RFC2328] [RFC5340]または中間システムから中間システム（IS-IS）[RFC1195]のいずれかと仮定します）" + }, + { + "indent": 3, + "text": "LSP:", + "ja": "LSP:" + }, + { + "indent": 12, + "text": "Label-Switched Path", + "ja": "ラベルスイッチパス" + }, + { + "indent": 3, + "text": "PCC:", + "ja": "PCC:" + }, + { + "indent": 12, + "text": "Path Computation Client (as per [RFC4655], any client application requesting a path computation to be performed by a PCE)", + "ja": "パス計算クライアント（[RFC4655]によると、PCEによって実行されるパス計算を要求するクライアントアプリケーション）" + }, + { + "indent": 3, + "text": "PCE:", + "ja": "PCE:" + }, + { + "indent": 12, + "text": "Path Computation Element (as per [RFC4655], an entity such as a component, application, or network node that is capable of computing a network path or route based on a network graph and applying computational constraints)", + "ja": "パス計算要素（[RFC4655]によると、ネットワークグラフに基づいてネットワークパスまたはルートを計算し、計算上の制約を適用できるコンポーネント、アプリケーション、またはネットワークノードなどのエンティティ）" + }, + { + "indent": 3, + "text": "PCECC:", + "ja": "PCECC：" + }, + { + "indent": 12, + "text": "PCE as a Central Controller (an extension of a PCE to support SDN functions as per [RFC8283])", + "ja": "中央コントローラーとしてのPCE（[RFC8283]に従ってSDN関数をサポートするPCEの拡張）" + }, + { + "indent": 3, + "text": "PST:", + "ja": "PST:" + }, + { + "indent": 12, + "text": "Path Setup Type [RFC8408]", + "ja": "パスセットアップタイプ[RFC8408]" + }, + { + "indent": 3, + "text": "RR:", + "ja": "RR:" + }, + { + "indent": 12, + "text": "Route Reflector [RFC4456]", + "ja": "ルートリフレクター[RFC4456]" + }, + { + "indent": 3, + "text": "SID:", + "ja": "SID:" + }, + { + "indent": 12, + "text": "Segment Identifier [RFC8402]", + "ja": "セグメント識別子[RFC8402]" + }, + { + "indent": 3, + "text": "SR:", + "ja": "SR:" + }, + { + "indent": 12, + "text": "Segment Routing [RFC8402]", + "ja": "セグメントルーティング[RFC8402]" + }, + { + "indent": 3, + "text": "SRGB:", + "ja": "SRGB：" + }, + { + "indent": 12, + "text": "Segment Routing Global Block [RFC8402]", + "ja": "セグメントルーティンググローバルブロック[RFC8402]" + }, + { + "indent": 3, + "text": "SRLB:", + "ja": "SRLB：" + }, + { + "indent": 12, + "text": "Segment Routing Local Block [RFC8402]", + "ja": "セグメントルーティングローカルブロック[RFC8402]" + }, + { + "indent": 3, + "text": "TE:", + "ja": "TE:" + }, + { + "indent": 12, + "text": "Traffic Engineering [RFC9522]", + "ja": "交通工学[RFC9522]" + }, + { + "indent": 0, + "text": "3. Use Cases", + "section_title": true, + "ja": "3. ユースケース" + }, + { + "indent": 3, + "text": "[RFC8283] describes various use cases for a PCECC such as:", + "ja": "[RFC8283]は、次のようなPCECCのさまざまなユースケースを説明しています。" + }, + { + "indent": 6, + "text": "* use of a PCECC to set up static TE LSPs (the PCEP extension for this use case is in [RFC9050])", + "ja": "* PCECCを使用して静的TE LSPをセットアップします（このユースケースのPCEP拡張は[RFC9050]にあります）" + }, + { + "indent": 6, + "text": "* use of a PCECC in SR [RFC8402]", + "ja": "* SR [RFC8402]でのPCECCの使用" + }, + { + "indent": 6, + "text": "* use of a PCECC to set up Multicast Point-to-Multipoint (P2MP) LSPs", + "ja": "* PCECCを使用してマルチキャストポイントツーマルチポイント（P2MP）LSP" + }, + { + "indent": 6, + "text": "* use of a PCECC to set up Service Function Chaining (SFC) [RFC7665]", + "ja": "* PCECCを使用してサービス関数チェーン（SFC）[RFC7665]をセットアップします" + }, + { + "indent": 6, + "text": "* use of a PCECC in optical networks", + "ja": "* 光ネットワークでのPCECCの使用" + }, + { + "indent": 3, + "text": "Section 3.1 describes the general case of a PCECC being in charge of managing MPLS label space, which is a prerequisite for further use cases. Further, various use cases (SR, Multicast, etc.) are described in the following sections to showcase scenarios that can benefit from the use of a PCECC.", + "ja": "セクション3.1では、MPLSラベルスペースの管理を担当するPCECCの一般的なケースについて説明します。これは、さらなるユースケースの前提条件です。さらに、PCECCの使用から利益を得ることができるシナリオを紹介するために、以下のセクションでさまざまなユースケース（SR、マルチキャストなど）について説明します。" + }, + { + "indent": 3, + "text": "It is interesting to note that some of the use cases listed can also be supported via BGP instead of PCEP. However, within the scope of this document, the focus is on the use of PCEP.", + "ja": "リストされているユースケースの一部は、PCEPの代わりにBGPを介してサポートできることに注意するのは興味深いことです。ただし、このドキュメントの範囲内では、PCEPの使用に焦点が当てられています。" + }, + { + "indent": 0, + "text": "3.1. PCECC for Label Management", + "section_title": true, + "ja": "3.1. ラベル管理用のPCECC" + }, + { + "indent": 3, + "text": "As per [RFC8283], in some cases, the PCECC can take responsibility for managing some part of the MPLS label space for each of the routers that it controls, and it may take wider responsibility for partitioning the label space for each router and allocating different parts for different uses, communicating the ranges to the router using PCEP.", + "ja": "[RFC8283]によると、場合によっては、PCECCは、制御する各ルーターのMPLSラベルスペースの一部を管理する責任を負う可能性があり、各ルーターのラベルスペースを分割し、異なる異なるものを割り当てる責任を負う可能性があります。さまざまな用途の部品、PCEPを使用してルーターに範囲を伝えます。" + }, + { + "indent": 3, + "text": "[RFC9050] describes a mode where LSPs are provisioned as explicit label instructions at each hop on the end-to-end path. Each router along the path must be told what label forwarding instructions to program and what resources to reserve. The controller uses PCEP to communicate with each router along the path of the end-to-end LSP. For this to work, the PCECC will take responsibility for managing some part of the MPLS label space for each of the routers that it controls. An extension to PCEP could be done to allow a PCC to inform the PCE of such a label space to control (see [PCE-ID] for a possible PCEP extension to support the advertisement of the MPLS label space for the PCE to control).", + "ja": "[RFC9050]は、LSPがエンドツーエンドパスの各ホップで明示的なラベル命令としてプロビジョニングされるモードを記述します。パスに沿った各ルーターは、プログラムするラベル転送指示と予約するリソースを伝える必要があります。コントローラーは、PCEPを使用して、エンドツーエンドLSPのパスに沿って各ルーターと通信します。これが機能するためには、PCECCは、制御する各ルーターのMPLSラベルスペースの一部を管理する責任を負います。PCCPの拡張機能は、PCCがこのようなラベルスペースのPCEに制御するための通知を許可するために実行できます（PCEを制御するためのMPLSラベルスペースの広告をサポートするために、可能なPCEP拡張について[PCE-ID]を参照）。" + }, + { + "indent": 3, + "text": "[RFC8664] specifies extensions to PCEP that allow a stateful PCE to compute, update, or initiate SR-TE paths. [PCECC-SR] describes the mechanism for a PCECC to allocate and provision the node/prefix/ adjacency label (Segment Routing Identifier (SID)) via PCEP. To make such an allocation, the PCE needs to be aware of the label space from the Segment Routing Global Block (SRGB) or Segment Routing Local Block (SRLB) [RFC8402] of the node that it controls. A mechanism for a PCC to inform the PCE of such a label space to control is needed within the PCEP. The full SRGB/SRLB of a node could be learned via existing IGP or BGP-LS [RFC9552] mechanisms.", + "ja": "[RFC8664]は、ステートフルPCEがSR-TEパスを計算、更新、または開始できるようにするPCEPへの拡張機能を指定します。[PCECC-SR]は、PCECCがPCEPを介してノード/プレフィックス/隣接ラベル（セグメントルーティング識別子（SID））を割り当ててプロビジョニングするメカニズムを説明しています。このような割り当てを行うには、PCEが、それが制御するノードのローカルブロック（SRLB）[RFC8402]をルーティングするセグメントルーティンググローバルブロック（SRGB）またはセグメントルーティングのラベルスペースを認識する必要があります。PCCがPCEを制御するためにPCEに通知するメカニズムがPCEP内で必要です。ノードの完全なSRGB/SRLBは、既存のIGPまたはBGP-LS [RFC9552]メカニズムを介して学習できます。" + }, + { + "indent": 3, + "text": "Further, there have been proposals for a global label range in MPLS as well as the use of PCECC architecture to learn the label space of each node to determine and provision the global label range.", + "ja": "さらに、MPLSのグローバルラベル範囲と、各ノードのラベルスペースを学習してグローバルラベル範囲を決定および提供するためのPCECCアーキテクチャの使用についての提案がありました。" + }, + { + "indent": 3, + "text": "+------------------------------+ +------------------------------+\n| PCE DOMAIN 1 | | PCE DOMAIN 2 |\n| +--------+ | | +--------+ |\n| | | | | | | |\n| | PCECC1 | ---------PCEP---------- | PCECC2 | |\n| | | | | | | |\n| | | | | | | |\n| +--------+ | | +--------+ |\n| ^ ^ | | ^ ^ |\n| / \\ PCEP | | PCEP / \\ |\n| V V | | V V |\n| +--------+ +--------+ | | +--------+ +--------+ |\n| | Node11 | | Node1n | | | | Node21 | | Node2n | |\n| | | ...... | | | | | | ...... | | |\n| | PCECC | | PCECC | | | | PCECC | |PCECC | |\n| |Enabled | | Enabled| | | |Enabled | |Enabled | |\n| +--------+ +--------+ | | +--------+ +--------+ |\n| | | |\n+------------------------------+ +------------------------------+", + "raw": true, + "ja": "" + }, + { + "indent": 17, + "text": "Figure 1: PCECC for MPLS Label Management", + "ja": "図1：MPLSラベル管理用PCECC" + }, + { + "indent": 3, + "text": "As shown in Figure 1:", + "ja": "図1に示すように：" + }, + { + "indent": 6, + "text": "* The PCC will advertise the PCECC capability to the PCECC [RFC9050].", + "ja": "* PCCは、PCECC機能をPCECC [RFC9050]に宣伝します。" + }, + { + "indent": 6, + "text": "* The PCECC could also learn the label range set aside by the PCC (via [PCE-ID]).", + "ja": "* PCECCは、PCC（[PCE-ID]を介して）によって確保されたラベル範囲を学習することもできます。" + }, + { + "indent": 6, + "text": "* Optionally, the PCECC could determine the shared MPLS global label range for the network.", + "ja": "* オプションで、PCECCはネットワークの共有MPLSグローバルラベル範囲を決定できます。" + }, + { + "indent": 12, + "text": "- In the case that the shared global label range needs to be negotiated across multiple domains, the central controllers of these domains will also need to negotiate a common global label range across domains.", + "ja": "- 共有されたグローバルラベル範囲を複数のドメインでネゴシエートする必要がある場合、これらのドメインの中央コントローラーは、ドメイン全体で共通のグローバルラベル範囲をネゴシエートする必要があります。" + }, + { + "indent": 12, + "text": "- The PCECC will need to set the shared global label range to all PCC nodes in the network.", + "ja": "- PCECCは、ネットワーク内のすべてのPCCノードに共有グローバルラベル範囲を設定する必要があります。" + }, + { + "indent": 3, + "text": "As per [RFC9050], the PCECC could also rely on the PCC to make label allocations initially and use PCEP to distribute it to where it is needed.", + "ja": "[RFC9050]によると、PCECCはPCCに依存してラベル割り当てを最初に行い、PCEPを使用して必要な場所に配布することもできます。" + }, + { + "indent": 0, + "text": "3.2. PCECC and SR", + "section_title": true, + "ja": "3.2. PCECCおよびSR" + }, + { + "indent": 3, + "text": "SR [RFC8402] leverages the source routing paradigm. Using SR, a source node steers a packet through a path without relying on hop-by-hop signalling protocols such as LDP [RFC5036] or RSVP-TE [RFC3209]. Each path is specified as an ordered list of instructions called \"segments\". Each segment is an instruction to route the packet to a specific place in the network or to perform a specific service on the packet. A database of segments can be distributed through the network using an intra-domain routing protocol (such as IS-IS or OSPF), an inter-domain protocol (such as BGP), or by any other means. PCEP could also be one of other protocols.", + "ja": "SR [RFC8402]は、ソースルーティングパラダイムを活用します。SRを使用して、ソースノードは、LDP [RFC5036]やRSVP-TE [RFC3209]などのホップバイホップシグナリングプロトコルに依存せずにパスをパケットに導きます。各パスは、「セグメント」と呼ばれる命令の順序付けリストとして指定されています。各セグメントは、パケットをネットワーク内の特定の場所にルーティングしたり、パケットで特定のサービスを実行する命令です。セグメントのデータベースは、ドメイン内ルーティングプロトコル（IS-ISやOSPFなど）、ドメイン間プロトコル（BGPなど）、またはその他の手段でネットワークを介して配布できます。PCEPは、他のプロトコルの1つでもあります。" + }, + { + "indent": 3, + "text": "[RFC8664] specifies the PCEP extension specific to SR for SR over MPLS (SR-MPLS). The PCECC may further use the PCEP for distributing SR Segment Identifiers (SIDs) to the SR nodes (PCC) with some benefits. If the PCECC allocates and maintains the SIDs in the network for the nodes and adjacencies, and further distributes them to the SR nodes directly via the PCEP session, then it is more advantageous over the configurations on each SR node and flooding them via IGP, especially in an SDN environment.", + "ja": "[RFC8664]は、MPLS（SR-MPLS）のSRのSRに固有のPCEP拡張を指定します。PCECCはさらに、SRセグメント識別子（SIDS）をSRノード（PCC）に分配するためにPCEPを使用して、いくつかの利点があります。PCECCがノードと隣接のネットワーク内のSIDを割り当てて維持し、PCEPセッションを介してSRノードにさらに配布する場合、各SRノードの構成よりも有利であり、特にIGPを介してそれらをあふれさせることはより有利です。SDN環境で。" + }, + { + "indent": 3, + "text": "When the PCECC is used for the distribution of the Node-SID and Adj-SID for SR-MPLS, the Node-SID is allocated from the SRGB of the node and the Adj-SID is allocated from the SRLB of the node as described in [PCECC-SR].", + "ja": "PCECCがSR-MPLS用のノードSIDおよびadj-SIDの分布に使用される場合、ノードSIDはノードのSRGBから割り当てられ、adj-SIDはノードのSRLBから割り当てられます。[PCECC-SR]。" + }, + { + "indent": 3, + "text": "[RFC8355] identifies various protection and resiliency use cases for SR. Path protection lets the ingress node be in charge of the failure recovery (used for SR-TE [RFC8664]). Also, protection can be performed by the node adjacent to the failed component, commonly referred to as \"local protection techniques\" or \"fast-reroute (FRR) techniques\". In the case of the PCECC, the protection paths can be precomputed and set up by the PCE.", + "ja": "[RFC8355]は、SRのさまざまな保護および回復力のユースケースを特定します。パス保護により、イングレスノードが障害回復を担当することができます（SR-TE [RFC8664]に使用）。また、保護は、一般に「ローカル保護技術」または「Fast-Reroute（FRR）技術」と呼ばれる故障コンポーネントに隣接するノードによって実行できます。PCECCの場合、PCEによって保護パスを事前計算して設定できます。" + }, + { + "indent": 3, + "text": "Figure 2 illustrates the use case where the Node-SID and Adj-SID are allocated by the PCECC for SR-MPLS.", + "ja": "図2は、SR-MPLSのためにPCECCによってノードSIDおよびadj-SIDが割り当てられるユースケースを示しています。" + }, + { + "indent": 8, + "text": " 192.0.2.1/32\n +----------+\n | R1(1001) |\n +----------+\n |\n +----------+\n | R2(1002) | 192.0.2.2/32\n +----------+\n * | * *\n * | * *\n *link1| * *\n192.0.2.4/32 * | *link2 * 192.0.2.5/32\n +-----------+ 9001| * +-----------+\n | R4(1004) | | * | R5(1005) |\n +-----------+ | * +-----------+\n * | *9003 * +\n * | * * +\n * | * * +\n +-----------+ +-----------+\n 192.0.2.3/32 | R3(1003) | |R6(1006) |192.0.2.6/32\n +-----------+ +-----------+\n |\n +-----------+\n | R8(1008) | 192.0.2.8/32\n +-----------+", + "raw": true, + "ja": "" + }, + { + "indent": 27, + "text": "Figure 2: SR Topology", + "ja": "図2：SRトポロジー" + }, + { + "indent": 0, + "text": "3.2.1. PCECC SID Allocation for SR-MPLS", + "section_title": true, + "ja": "3.2.1. SR-MPLSのPCECC SID割り当て" + }, + { + "indent": 3, + "text": "Each node (PCC) is allocated a Node-SID by the PCECC. The PCECC needs to update the label mapping of each node to all the other nodes in the domain. After receiving the label mapping, each node (PCC) uses the local routing information to determine the next hop and download the label forwarding instructions accordingly. The forwarding behavior and the end result are the same as IGP shortest-path SR forwarding based on Node-SIDs. Thus, from anywhere in the domain, it enforces the ECMP-aware shortest-path forwarding of the packet towards the related node.", + "ja": "各ノード（PCC）は、PCECCによってノードSIDを割り当てられます。PCECCは、各ノードのラベルマッピングをドメイン内の他のすべてのノードに更新する必要があります。ラベルマッピングを受信した後、各ノード（PCC）はローカルルーティング情報を使用して次のホップを決定し、それに応じてラベル転送手順をダウンロードします。転送の動作と最終結果は、ノードSIDに基づくIGP最短パスSR転送と同じです。したがって、ドメインのどこからでも、関連するノードに向けてパケットのECMPを認識している最短パス転送を実施します。" + }, + { + "indent": 3, + "text": "The PCECC can allocate an Adj-SID for each adjacency in the network. The PCECC sends a PCInitiate message to update the label mapping of each adjacency to the corresponding nodes in the domain. Each node (PCC) downloads the label forwarding instructions accordingly. The forwarding behavior and the end result are similar to IGP-based Adj-SID allocation and usage in SR.", + "ja": "PCECCは、ネットワーク内の各隣接にadj-SIDを割り当てることができます。PCECCはPCINITIATEメッセージを送信して、各隣接のラベルマッピングをドメイン内の対応するノードに更新します。各ノード（PCC）は、それに応じてラベル転送手順をダウンロードします。転送挙動と最終結果は、SRのIGPベースのADJ-SID割り当てと使用に似ています。" + }, + { + "indent": 3, + "text": "These mechanisms are described in [PCECC-SR].", + "ja": "これらのメカニズムは[PCECC-SR]で説明されています。" + }, + { + "indent": 0, + "text": "3.2.2. PCECC for SR-MPLS Best Effort (BE) Paths", + "section_title": true, + "ja": "3.2.2. SR-MPLSのPCECC最善の努力（BE）パス" + }, + { + "indent": 3, + "text": "When using PCECC for SR-MPLS Best Effort (BE) Paths, the PCECC needs to allocate the Node-SID (without calculating the explicit path for the SR path). The ingress router of the forwarding path needs to encapsulate the destination Node-SID on top of the packet. All the intermediate nodes will forward the packet based on the destination Node-SID. It is similar to the LDP LSP.", + "ja": "SR-MPLSの最善の努力（BE）パスにPCECCを使用する場合、PCECCはノードSIDを割り当てる必要があります（SRパスの明示的なパスを計算せずに）。転送パスのイングレスルーターは、パケットの上に宛先ノードSIDをカプセル化する必要があります。すべての中間ノードは、宛先ノードSIDに基づいてパケットを転送します。LDP LSPに似ています。" + }, + { + "indent": 3, + "text": "R1 may send a packet to R8 simply by pushing an SR label with segment {1008} (Node-SID for R8). The path will be based on the routing / next hop calculation on the routers.", + "ja": "R1は、SRラベルをセグメント{1008}（R8用のノードSID）でプッシュするだけで、R8にパケットを送信できます。パスは、ルーターのルーティング /次のホップ計算に基づいています。" + }, + { + "indent": 0, + "text": "3.2.3. PCECC for SR-MPLS TE Paths", + "section_title": true, + "ja": "3.2.3. SR-MPLS TEパス用のPCECC" + }, + { + "indent": 3, + "text": "SR-TE paths may not follow an IGP shortest path tree (SPT). Such paths may be chosen by a PCECC and provisioned on the ingress node of the SR-TE path. The SR header consists of a list of SIDs (or MPLS labels). The header has all necessary information so that the packets can be guided from the ingress node to the egress node of the path. Hence, there is no need for any signalling protocol. For the case where a strict traffic engineering path is needed, all the Adj-SIDs are stacked; otherwise, a combination of Node-SIDs or Adj-SIDs can be used for the SR-TE paths.", + "ja": "SR-TEパスは、IGP最短パスツリー（SPT）をたどることはできません。このようなパスは、PCECCによって選択され、SR-TEパスのイングレスノードにプロビジョニングされる場合があります。SRヘッダーは、SIDS（またはMPLSラベル）のリストで構成されています。ヘッダーにはすべての必要な情報があるため、パケットをイングレスノードからパスの出力ノードに誘導できます。したがって、シグナル伝達プロトコルは必要ありません。厳格な交通工学パスが必要な場合、すべてのadj-SIDが積み重ねられます。それ以外の場合、SR-TEパスにノードSIDまたはADJ-SIDの組み合わせを使用できます。" + }, + { + "indent": 3, + "text": "As shown in Figure 3, R1 may send a packet to R8 by pushing an SR header with segment list {1002, 9001, 1008}, where 1002 and 1008 are the Node-SIDs of R2 and R8, respectively. 9001 is the Adj-SID for link1. The path should be: \"R1-R2-link1-R3-R8\".", + "ja": "図3に示すように、R1は、セグメントリスト{1002、9001、1008}でSRヘッダーをプッシュすることによりR8にパケットを送信する場合があります。1002と1008はそれぞれR2とR8のノードシドです。9001は、link1のadj-sidです。パスは次のとおりです。「R1-R2-Link1-R3-R8」。" + }, + { + "indent": 3, + "text": "To achieve this, the PCECC first allocates and distributes SIDs as described in Section 3.2.1. [RFC8664] describes the mechanism for a PCE to compute, update, or initiate SR-MPLS TE paths.", + "ja": "これを達成するために、PCECCは、セクション3.2.1で説明されているように、最初にSIDを割り当てて配布します。[RFC8664]は、PCEがSR-MPLS TEパスを計算、更新、または開始するメカニズムを説明しています。" + }, + { + "indent": 8, + "text": " 192.0.2.1/32\n +----------+\n | R1 (1001)|\n +----------+\n | |\n 90011 | |90012\n link1 | |link2\n +----------+\n | R2 (1002)| 192.0.2.2/32\n +----------+\n link3 * | * * link4\n 90023 * | * * 90024\n *link5| * *\n192.0.2.4/32 *90025 | *link6 * 192.0.2.5/32\n +-----------+ | *90026+-----------+\n | R4 (1004) | | * | R5 (1005) |\n +-----------+ | * +-----------+\n * | * +\n link10 * | * link7 +\n * | * +\n +-----------+ +-----------+\n 192.0.2.3/32 | R3 (1003) | |R6 (1006) |192.0.2.6/32\n +-----------+ +-----------+\n | |\n |link8 |\n | |----------|link9\n +-----------+\n | R8 (1008) | 192.0.2.8/32\n +-----------+", + "raw": true, + "ja": "" + }, + { + "indent": 20, + "text": "Figure 3: PCECC TE LSP Setup Example", + "ja": "図3：PCECC TE LSPセットアップの例" + }, + { + "indent": 3, + "text": "Refer to Figure 3 for an example of TE topology, where 100x are Node-SIDs and 900xx are Adj-SIDs.", + "ja": "TEトポロジの例については、図3を参照してください。100xはノードシドで、900xxはadj-sidsです。" + }, + { + "indent": 6, + "text": "* The SID allocation and distribution are done by the PCECC with all Node-SIDs (100x) and all Adj-SIDs (900xx).", + "ja": "* SIDの割り当てと分布は、すべてのノードSID（100x）およびすべてのadj-SID（900xx）を備えたPCECCによって行われます。" + }, + { + "indent": 6, + "text": "* Based on path computation request/delegation or PCE initiation, the PCECC receives a request with constraints and optimization criteria from a PCC.", + "ja": "* PATH計算要求/委任またはPCEの開始に基づいて、PCECCはPCCから制約と最適化基準を備えた要求を受け取ります。" + }, + { + "indent": 6, + "text": "* The PCECC will calculate the optimal path according to the given constraints (e.g., bandwidth (BW)).", + "ja": "* PCECCは、指定された制約（例：帯域幅（BW））に従って最適なパスを計算します。" + }, + { + "indent": 6, + "text": "* The PCECC will provision the SR-MPLS TE LSP path (\"R1-link1-R2-link6-R3-R8\") at the ingress node: {90011, 1002, 90026, 1003, 1008}", + "ja": "* PCECCは、SR-MPLS TE LSPパス（ \"R1-Link1-R2-Link6-R3-R8\"）をIngressノードにプロビジョニングします：{90011、1002、90026、1003、1008}" + }, + { + "indent": 6, + "text": "* For the end-to-end protection, the PCECC can provision the secondary path (\"R1-link2-R2-link4-R5-R8\"): {90012, 1002, 90024, 1005, 1008}.", + "ja": "* エンドツーエンドの保護のために、PCECCはセカンダリパス（ \"R1-Link2-R2-Link4-R5-R8\"）をプロビジョニングできます：{90012、1002、90024、1005、1008}。" + }, + { + "indent": 0, + "text": "3.2.3.1. PCECC for SR Policy", + "section_title": true, + "ja": "3.2.3.1. SRポリシーのPCECC" + }, + { + "indent": 3, + "text": "[RFC8402] defines SR architecture, which uses an SR Policy to steer packets from a node through an ordered list of segments. The SR Policy could be configured on the headend or instantiated by an SR controller. The SR architecture does not restrict how the controller programs the network. In this case, the focus is on PCEP as the protocol for SR Policy delivery from the PCE to PCC.", + "ja": "[RFC8402]は、SRアーキテクチャを定義します。SRアーキテクチャは、SRポリシーを使用して、順序付けられたセグメントリストを介してノードからパケットを操縦します。SRポリシーは、ヘッドエンドで構成するか、SRコントローラーによってインスタンス化される可能性があります。SRアーキテクチャは、コントローラーがネットワークをどのようにプログラムするかを制限していません。この場合、PCCからPCCへのSRポリシー提供のプロトコルとしてのPCEPに焦点が当てられています。" + }, + { + "indent": 3, + "text": "An SR Policy architecture is described in [RFC9256]. An SR Policy is a framework that enables the instantiation of an ordered list of segments on a node for implementing a source routing policy for the steering of traffic for a specific purpose (e.g., for a specific Service Level Agreement (SLA)) from that node.", + "ja": "SRポリシーアーキテクチャは[RFC9256]で説明されています。SRポリシーは、特定の目的のためのトラフィックのステアリング（例：特定のサービスレベル契約（SLA）など）のソースルーティングポリシーを実装するためのノード上の順序付けられたセグメントリストのインスタンス化を可能にするフレームワークです。。" + }, + { + "indent": 3, + "text": "An SR Policy is identified through the tuple .", + "ja": "SRポリシーは、tuple を通じて識別されます。" + }, + { + "indent": 3, + "text": "Figure 3 is used as an example of PCECC application for SR Policy instantiation for SR-MPLS, where the Node-SIDs are 100x and the Adj-SIDs are 900xx.", + "ja": "図3は、SR-MPLSのSRポリシーインスタンス化のためのPCECCアプリケーションの例として使用されます。ここで、ノードSIDは100倍で、Adj-SIDは900XXです。" + }, + { + "indent": 3, + "text": "Let's assume that R1 needs to have two disjoint SR Policies towards R8 based on different BWs. This means the possible paths are:", + "ja": "R1は、異なるBWSに基づいてR8に対して2つのばらばらのSRポリシーを持つ必要があると仮定しましょう。これは、可能なパスが次のことを意味します。" + }, + { + "indent": 6, + "text": "* POL1: {Headend R1, color 100, Endpoint R8; Candidate Path1: Segment List 1: {90011, 1002, 90023, 1004, 1003, 1008}}", + "ja": "* pol1：{headend R1、Color 100、Endpoint R8;候補PATH1：セグメントリスト1：{90011、1002、90023、1004、1003、1008}}" + }, + { + "indent": 6, + "text": "* POL2: {Headend R1, color 200, Endpoint R8; Candidate Path1: Segment List 1: {90012, 1002, 90024, 1005, 1006, 1008}}", + "ja": "* POL2：{HeadEnd R1、Color 200、Endpoint R8;候補PATH1：セグメントリスト1：{90012、1002、90024、1005、1006、1008}}}" + }, + { + "indent": 3, + "text": "Each SR Policy (including the candidate path and segment list) will be signalled to a headend (R1) via PCEP [PCEP-POLICY] with the addition of an ASSOCIATION object. A Binding SID (BSID) [RFC8402] can be used for traffic steering of labelled traffic into an SR Policy; a BSID can be provisioned from the PCECC also via PCEP [RFC9604]. For non-labelled traffic steering into the SR Policy POL1 or POL2, a per-destination traffic steering will be used by means of the BGP Color Extended Community [RFC9012].", + "ja": "各SRポリシー（候補パスとセグメントリストを含む）は、Associationオブジェクトを追加して、PCEP [PCEP-Policy]を介してヘッドエンド（R1）に通知されます。バインディングSID（BSID）[RFC8402]は、SRポリシーへのラベル付きトラフィックのトラフィックステアリングに使用できます。BSIDは、PCEP [RFC9604]を介してPCECCからプロビジョニングできます。SRポリシーPOL1またはPOL2への非標識トラフィックステアリングの場合、BGPカラーの拡張コミュニティ[RFC9012]によって、設定ごとのトラフィックステアリングが使用されます。" + }, + { + "indent": 3, + "text": "The procedure is as follows:", + "ja": "手順は次のとおりです。" + }, + { + "indent": 6, + "text": "* The PCECC allocates Node-SIDs and Adj-SIDs using the mechanism described in Section 3.2.1 for all nodes and links.", + "ja": "* PCECCは、すべてのノードとリンクについてセクション3.2.1で説明したメカニズムを使用して、ノードSIDとadj-SIDを割り当てます。" + }, + { + "indent": 6, + "text": "* The PCECC calculates disjoint paths for POL1 and POL2 and create segment lists for them: {90011, 1002, 90023, 1004, 1003, 1008};{90012, 1002, 90024, 1005, 1006, 1008}.", + "ja": "* PCECCは、POL1およびPOL2の分離パスを計算し、それらのセグメントリストを作成します：{90011、1002、90023、1004、1003、1008}; {90012、1002、90024、1005、1006、1008}。" + }, + { + "indent": 6, + "text": "* The PCECC forms both SR Policies POL1 and POL2.", + "ja": "* PCECCは、SRポリシーPOL1とPOL2の両方を形成します。" + }, + { + "indent": 6, + "text": "* The PCECC sends both POL1 and POL2 to R1 via PCEP.", + "ja": "* PCECCは、PCEPを介してPOL1とPOL2の両方をR1に送信します。" + }, + { + "indent": 6, + "text": "* The PCECC optionally allocates BSIDs for the SR Policies.", + "ja": "* PCECCはオプションで、SRポリシーにBSIDを割り当てます。" + }, + { + "indent": 6, + "text": "* The traffic from R1 to R8, which fits to color 100, will be steered to POL1 and follows the path: \"R1-link1-R2-link3-R4-R3-R8\". The traffic from R1 to R8, which fits color 200, will be steered to POL2 and follows the path: \"R1-link2-R2-link4-R5-R6-R8\". Due to the possibility of having many segment lists in the same candidate path of each POL1/POL2, the PCECC could provision more paths towards R8 and traffic will be balanced either as ECMP or as weighted-ECMP (W-ECMP). This is the advantage of SR Policy architecture.", + "ja": "* R1からR8へのトラフィックは、100色に収まり、POL1に操縦され、パス「R1-Link1-R2-Link3-R4-R3-R8」に従います。Color 200に適合するR1からR8へのトラフィックはPOL2に操縦され、パス「R1-Link2-R2-Link4-R5-R6-R8」に従います。各POL1/POL2の同じ候補パスに多くのセグメントリストを持つ可能性があるため、PCECCはR8へのより多くのパスを提供することができ、トラフィックはECMPまたは加重ECMP（W-ECMP）としてバランスが取れます。これがSRポリシーアーキテクチャの利点です。" + }, + { + "indent": 3, + "text": "Note that an SR Policy can be associated with multiple candidate paths. A candidate path is selected when it is valid and it is determined to be the best path of the SR Policy as described in [RFC9256].", + "ja": "SRポリシーは、複数の候補パスに関連付けられる可能性があることに注意してください。[RFC9256]で説明されているように、候補パスが有効である場合に選択され、SRポリシーの最良のパスであると判断されます。" + }, + { + "indent": 0, + "text": "3.2.4. PCECC for SRv6", + "section_title": true, + "ja": "3.2.4. SRV6用PCECC" + }, + { + "indent": 3, + "text": "As per [RFC8402], with SR, a node steers a packet through an ordered list of instructions, called segments. SR can be applied to the IPv6 architecture with the Segment Routing Header (SRH) [RFC8754]. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the destination address of the packet. Upon completion of a segment, a pointer in the new routing header is incremented and indicates the next segment.", + "ja": "[RFC8402]によると、SRを使用して、ノードは、セグメントと呼ばれる順序付けられた命令リストを介してパケットを操縦します。SRは、セグメントルーティングヘッダー（SRH）[RFC8754]を使用してIPv6アーキテクチャに適用できます。セグメントはIPv6アドレスとしてエンコードされます。セグメントの順序付けられたリストは、ルーティングヘッダーのIPv6アドレスの順序付けリストとしてエンコードされています。アクティブセグメントは、パケットの宛先アドレスで示されています。セグメントが完了すると、新しいルーティングヘッダーのポインターが増加し、次のセグメントを示します。" + }, + { + "indent": 3, + "text": "As per [RFC8754], an SR over IPv6 (SRv6) Segment is a 128-bit value. \"SRv6 SID\" or simply \"SID\" are often used as a shorter reference for \"SRv6 Segment\". [RFC8986] defines the SRv6 SID as consisting of LOC:FUNCT:ARG.", + "ja": "[RFC8754]によると、IPv6（SRV6）セグメント上のSRは128ビット値です。「SRV6 SID」または単に「SID」は、「SRV6セグメント」のより短い参照としてよく使用されます。[RFC8986]は、SRV6 SIDをloc：funct：argで構成されるものとして定義します。" + }, + { + "indent": 3, + "text": "[RFC9603] extends [RFC8664] to support SR for the IPv6 data plane. Further, a PCECC could be extended to support SRv6 SID allocation and distribution. An example of how PCEP extensions could be extended for SRv6 for a PCECC is described in [PCECC-SRv6].", + "ja": "[RFC9603]は[RFC8664]を拡張して、IPv6データプレーンのSRをサポートします。さらに、SRV6 SIDの割り当てと分布をサポートするためにPCECCを拡張できます。PCECCのSRV6のPCEP拡張機能をどのように拡張できるかの例は、[PCECC-SRV6]で説明されています。" + }, + { + "indent": 8, + "text": " 2001:db8::1\n +----------+\n | R1 |\n +----------+\n |\n +----------+\n | R2 | 2001:db8::2\n +----------+\n * | * *\n * | * *\n *link1| * *\n2001:db8::4 * | *link2 * 2001:db8::5\n +-----------+ | * +-----------+\n | R4 | | * | R5 |\n +-----------+ | * +-----------+\n * | * * +\n * | * * +\n * | * * +\n +-----------+ +-----------+\n 2001:db8::3 | R3 | |R6 |2001:db8::6\n +-----------+ +-----------+\n |\n +-----------+\n | R8 | 2001:db8::8\n +-----------+", + "raw": true, + "ja": "" + }, + { + "indent": 26, + "text": "Figure 4: PCECC for SRv6", + "ja": "図4：SRV6のPCECC" + }, + { + "indent": 3, + "text": "In this case, as shown in Figure 4, the PCECC could assign the SRv6 SID (in the form of an IPv6 address) to be used for node and adjacency. Later, the SRv6 path in the form of a list of SRv6 SIDs could be used at the ingress. Some examples:", + "ja": "この場合、図4に示すように、PCECCはSRV6 SID（IPv6アドレスの形で）を割り当てて、ノードと隣接に使用できます。その後、SRV6 SIDのリストの形のSRV6パスをイングレスで使用できます。いくつかの例：" + }, + { + "indent": 6, + "text": "* The best path towards R8: SRv6 SID-List={2001:db8::8}", + "ja": "* R8への最適なパス：SRV6 SID-LIST = {2001：DB8 :: 8}" + }, + { + "indent": 6, + "text": "* The path towards R8 via R5: SRv6 SID-List={2001:db8::5, 2001:db8::8}", + "ja": "* R5を介したR8へのパス：SRV6 SID-LIST = {2001：DB8 :: 5、2001：DB8 :: 8}" + }, + { + "indent": 3, + "text": "The rest of the procedures and mechanisms remain the same as SR-MPLS.", + "ja": "残りの手順とメカニズムは、SR-MPLと同じままです。" + }, + { + "indent": 0, + "text": "3.3. PCECC for Static TE LSPs", + "section_title": true, + "ja": "3.3. 静的te LSPのPCECC" + }, + { + "indent": 3, + "text": "As described in Section 3.1.2 of [RFC8283], the PCECC architecture supports the provisioning of static TE LSPs. To achieve this, the existing PCEP can be used to communicate between the PCECC and nodes along the path to provision explicit label instructions at each hop on the end-to-end path. Each router along the path must be told what label-forwarding instructions to program and what resources to reserve. The PCECC keeps a view of the network and determines the paths of the end-to-end LSPs, and the controller uses PCEP to communicate with each router along the path of the end-to-end LSP.", + "ja": "[RFC8283]のセクション3.1.2で説明されているように、PCECCアーキテクチャは静的TE LSPのプロビジョニングをサポートしています。これを達成するために、既存のPCEPを使用して、パスに沿ってPCECCとノード間を通信して、エンドツーエンドパスの各ホップで明示的なラベル命令を提供します。パスに沿った各ルーターは、プログラムするためのラベルフォード指示と予約するリソースを伝える必要があります。PCECCはネットワークのビューを保持し、エンドツーエンドLSPのパスを決定し、コントローラーはPCEPを使用して、エンドツーエンドLSPのパスに沿って各ルーターと通信します。" + }, + { + "indent": 8, + "text": " 192.0.2.1/32\n +----------+\n | R1 |\n +----------+\n | |\n |link1 |\n | |link2\n +----------+\n | R2 | 192.0.2.2/32\n +----------+\n link3 * | * * link4\n * | * *\n *link5| * *\n192.0.2.4/32 * | *link6 * 192.0.2.5/32\n +-----------+ | * +-----------+\n | R4 | | * | R5 |\n +-----------+ | * +-----------+\n * | * * +\n link10 * | * *link7 +\n * | * * +\n +-----------+ +-----------+\n 192.0.2.3/32 | R3 | |R6 |192.0.2.6/32\n +-----------+ +-----------+\n | |\n |link8 |\n | |link9\n +-----------+\n | R8 | 192.0.2.8/32\n +-----------+", + "raw": true, + "ja": "" + }, + { + "indent": 20, + "text": "Figure 5: PCECC TE LSP Setup Example", + "ja": "図5：PCECC TE LSPセットアップの例" + }, + { + "indent": 3, + "text": "Refer to Figure 5 for an example TE topology.", + "ja": "TEトポロジの例については、図5を参照してください。" + }, + { + "indent": 6, + "text": "* Based on path computation request/delegation or PCE initiation, the PCECC receives a request with constraints and optimization criteria.", + "ja": "* PATH計算要求/委任またはPCEの開始に基づいて、PCECCは制約と最適化基準を備えた要求を受け取ります。" + }, + { + "indent": 6, + "text": "* The PCECC will calculate the optimal path according to the given constraints (e.g., BW).", + "ja": "* PCECCは、指定された制約（例：BW）に従って最適なパスを計算します。" + }, + { + "indent": 6, + "text": "* The PCECC will provision each node along the path and assign incoming and outgoing labels from R1 to R8 with the path as \"R1-link1-R2-link3-R4-link10-R3-link8-R8\":", + "ja": "* PCECCは、パスに沿って各ノードをプロビジョニングし、パスを「R1-LINK1-R2-LINK3-RINK10-RINK8-R8」とともにR1からR8に割り当てます：" + }, + { + "indent": 12, + "text": "- R1: Outgoing label 1001 on link 1", + "ja": "- R1：リンク1の発信ラベル1001" + }, + { + "indent": 12, + "text": "- R2: Incoming label 1001 on link 1", + "ja": "- R2：リンク1の着信ラベル1001" + }, + { + "indent": 12, + "text": "- R2: Outgoing label 2003 on link 3", + "ja": "- R2：リンク3の発信ラベル2003" + }, + { + "indent": 12, + "text": "- R4: Incoming label 2003 on link 3", + "ja": "- R4：リンク3の着信ラベル2003" + }, + { + "indent": 12, + "text": "- R4: Outgoing label 4010 on link 10", + "ja": "- R4：リンク10の発信ラベル4010" + }, + { + "indent": 12, + "text": "- R3: Incoming label 4010 on link 10", + "ja": "- R3：リンク10の着信ラベル4010" + }, + { + "indent": 12, + "text": "- R3: Outgoing label 3008 on link 8", + "ja": "- R3：リンク8の発信ラベル3008" + }, + { + "indent": 12, + "text": "- R8: Incoming label 3008 on link 8", + "ja": "- R8：リンク8の着信ラベル3008" + }, + { + "indent": 6, + "text": "* This can also be represented as: {R1, link1, 1001}, {1001, R2, link3, 2003}, {2003, R4, link10, 4010}, {4010, R3, link8, 3008}, {3008, R8}.", + "ja": "* これは、{r1、link1、1001}、{1001、r2、link3、2003}、{2003、r4、link10、4010}、{4010、r3、link8、3008}、{3008、r8}として次のように表現できます。。" + }, + { + "indent": 6, + "text": "* For the end-to-end protection, the PCECC programs each node along the path from R1 to R8 with the secondary path: {R1, link2, 1002}, {1002, R2, link4, 2004}, {2004, R5, link7, 5007}, {5007, R3, link9, 3009}, {3009, R8}.", + "ja": "* エンドツーエンドの保護のために、PCECCは各ノードをR1からR8へのパスに沿ったセカンダリパスでプログラムします：{r1、link2、1002}、{1002、r2、link4、2004}、{2004、r5、link7、5007}、{5007、r3、link9、3009}、{3009、r8}。" + }, + { + "indent": 6, + "text": "* It is also possible to have a bypass path for the local protection set up by the PCECC. For example, use the primary path as above, then to protect the node R4 locally, the PCECC can program the bypass path like this: {R2, link5, 2005}, {2005, R3}. By doing this, the node R4 is locally protected at R2.", + "ja": "* PCECCによって設定されたローカル保護のバイパスパスを持つこともできます。たとえば、上記のプライマリパスを使用してから、ノードR4をローカルで保護するために、PCECCは次のようなバイパスパスをプログラムできます：{r2、link5、2005}、{2005、r3}。これを行うことにより、ノードR4はR2でローカルで保護されています。" + }, + { + "indent": 0, + "text": "3.4. PCECC for Load Balancing (LB)", + "section_title": true, + "ja": "3.4. ロードバランシング用PCECC（LB）" + }, + { + "indent": 3, + "text": "Very often, many service providers use TE tunnels for solving issues with non-deterministic paths in their networks. One example of such applications is the usage of TEs in the mobile backhaul (MBH). Consider the topology as shown in Figure 6 (where AGG 1...AGG N are Aggregation routers, and Core 1...Core N are Core routers).", + "ja": "多くの場合、多くのサービスプロバイダーは、ネットワーク内の非決定的なパスの問題を解決するためにTEトンネルを使用しています。このようなアプリケーションの1つの例は、モバイルバックホール（MBH）でのTEの使用です。図6に示すようにトポロジーを考えてみましょう（Agg 1 ... Agg nは集約ルーター、コア1 ...コアnはコアルーターです）。" + }, + { + "indent": 3, + "text": " TE1 ----------->\n+--------+ +------+ +-----+ +-------+ +------+ +---+\n|Access |----|Access|----|AGG 1|----|AGG N-1|----|Core 1|--|SR1|\n|SubNode1| |Node1 | +-----+ +-------+ +------+ +---+\n+--------+ +------+ | | | ^ |\n | Access | Access | AGG Ring 1| | |\n | SubRing 1 | Ring 1 | | | | |\n+--------+ +------+ +-----+ | | |\n|Access | |Access| |AGG 2| | | |\n|SubNode2| |Node2 | +-----+ | | |\n+--------+ +------+ | | | | |\n | | | | | | |\n | | | +---TE2---|-+ |\n+--------+ +------+ +-----+ +-------+ +------+ +---+\n|Access | |Access|----|AGG 3|----| AGG N |----|Core N|--|SRn|\n|SubNodeN|----|NodeN | +-----+ +-------+ +------+ +---+\n+--------+ +------+", + "raw": true, + "ja": "" + }, + { + "indent": 24, + "text": "Figure 6: PCECC LB Use Case", + "ja": "図6：PCECC LBユースケース" + }, + { + "indent": 3, + "text": "This MBH architecture uses L2 access rings and sub-rings. L3 starts at the aggregation layer. For the sake of simplicity, the figure shows only one access sub-ring. The access ring and aggregation ring are connected by Nx10GE interfaces. The aggregation domain runs its own IGP. There are two egress routers (AGG N-1 and AGG N) that are connected to the Core domain (Core 1...Core N) via L2 interfaces. The Core also has connections to service routers; RSVP-TE or SR-TE is used for MPLS transport inside the ring. There could be at least two tunnels (one way) from each AGG router to egress AGG routers. There are also many L2 access rings connected to AGG routers.", + "ja": "このMBHアーキテクチャは、L2アクセスリングとサブリングを使用しています。L3は集約層から始まります。簡単にするために、この図は1つのアクセスサブリングのみを示しています。アクセスリングと集約リングは、NX10GEインターフェイスで接続されています。集約ドメインは独自のIGPを実行します。L2インターフェイスを介してコアドメイン（コア1 ...コアN）に接続されている2つの出力ルーター（AGG N-1とAGG N）があります。コアには、サービスルーターへの接続もあります。RSVP-TEまたはSR-TEは、リング内のMPLS輸送に使用されます。各AGGルーターから少なくとも2つのトンネル（1つの方法）がある可能性があります。AGGルーターに接続された多くのL2アクセスリングもあります。" + }, + { + "indent": 3, + "text": "Service deployment is made by means of Layer 2 Virtual Private Networks (L2VPNs), Virtual Private LAN Services (VPLSs), Layer 3 Virtual Private Networks (L3VPNs), or Ethernet VPNs (EVPNs). Those services use MPLS TE (or SR-TE) as transport towards egress AGG routers. TE tunnels could be used as transport towards service routers in case of architecture based on seamless MPLS [MPLS-SEAMLESS].", + "ja": "サービスの展開は、レイヤー2仮想プライベートネットワーク（L2VPNS）、仮想プライベートLANサービス（VPLSS）、レイヤー3仮想プライベートネットワーク（L3VPNS）、またはイーサネットVPN（EVPN）によって行われます。これらのサービスは、MPLS TE（またはSR-TE）を出力アグルーターへの輸送として使用します。TEトンネルは、シームレスMPL [MPLSシームレス]に基づいたアーキテクチャの場合、サービスルーターへの輸送として使用できます。" + }, + { + "indent": 3, + "text": "Load Balancing (LB) between TE tunnels involves distributing network traffic across multiple TE tunnels to optimize the use of available network resources, enhance performance, and ensure reliability. Some common techniques include Equal-Cost Multipath (ECMP) and Unequal-Cost Multipath (UCMP) based on the BW of the TE tunnels.", + "ja": "TEトンネル間の負荷分散（LB）には、利用可能なネットワークリソースの使用を最適化し、パフォーマンスを向上させ、信頼性を確保するために、複数のTEトンネルにネットワークトラフィックを配布することが含まれます。いくつかの一般的な手法には、TEトンネルのBWに基づく等しいマルチパス（ECMP）および不平等なコストマルチパス（UCMP）が含まれます。" + }, + { + "indent": 3, + "text": "There is a need to solve the following tasks:", + "ja": "次のタスクを解決する必要があります。" + }, + { + "indent": 6, + "text": "* Perform automatic LB amongst TE tunnels according to current traffic loads.", + "ja": "* 現在のトラフィック負荷に応じて、トンネル間で自動LBを実行します。" + }, + { + "indent": 6, + "text": "* Manage TE BW by guaranteeing BW for specific services (such as High-Speed Internet (HSI), IPTV, etc.) and enabling time-based BW reservation (such as Bandwidth on Demand (BoD)).", + "ja": "* 特定のサービス（高速インターネット（HSI）、IPTVなど）のBWを保証し、時間ベースのBW予約（帯域幅オンデマンド（BOD）など）を保証することにより、TE BWを管理します。" + }, + { + "indent": 6, + "text": "* Simplify the development of TE tunnels by automation without any manual intervention.", + "ja": "* 手動で介入することなく、自動化によりTEトンネルの開発を簡素化します。" + }, + { + "indent": 6, + "text": "* Provide flexibility for service router placement (anywhere in the network by the creation of transport LSPs to them).", + "ja": "* サービスルーターの配置に柔軟性を提供します（輸送LSPを作成することにより、ネットワーク内のどこでも）。" + }, + { + "indent": 3, + "text": "In this section, the focus is on LB tasks. LB tasks could be solved by means of the PCECC in the following ways:", + "ja": "このセクションでは、LBタスクに焦点を当てています。LBタスクは、次の方法でPCECCによって解決できます。" + }, + { + "indent": 6, + "text": "* Applications, network services, or operators can ask the SDN controller (PCECC) for LSP-based LB between AGG X and AGG N/AGG N-1 (egress AGG routers that have connections to the core). Each of these will have associated constraints (such as BW, inclusion or exclusion of specific links or nodes, number of paths, Objective Function (OF), need for disjoint LSP paths, etc.).", + "ja": "* アプリケーション、ネットワークサービス、またはオペレーターは、AGG XとAGG N/AGG N-1（コアに接続する出力AGGルーター）の間のLSPベースのLBについて、SDNコントローラー（PCECC）に尋ねることができます。これらのそれぞれには、関連する制約（BW、包含または特定のリンクまたはノードの除外、パス数、目的関数（）、馬鹿げたLSPパスの必要性など）があります。" + }, + { + "indent": 6, + "text": "* The PCECC could calculate multiple (say N) LSPs according to given constraints. The calculation is based on the results of the OF [RFC5541], constraints, endpoints, same or different BW, different links (in case of disjoint paths), and other constraints.", + "ja": "* PCECCは、与えられた制約に従って複数の（たとえばn）LSPを計算できます。計算は、[RFC5541]の結果、制約、エンドポイント、同じまたは異なるBW、異なるリンク（不利な経路の場合）、およびその他の制約の結果に基づいています。" + }, + { + "indent": 6, + "text": "* Depending on the given LSP PST, the PCECC will download instructions to the PCC. At this stage, it is assumed the PCECC is aware of the label space it controls and SID allocation and distribution is already done in the case of SR.", + "ja": "* 指定されたLSP PSTに応じて、PCECCはPCCに手順をダウンロードします。この段階では、PCECCが制御するラベル空間を認識しており、SIDの割り当てと分布はSRの場合にすでに行われています。" + }, + { + "indent": 6, + "text": "* The PCECC will send a PCInitiate message [RFC8281] towards the ingress AGG X router (PCC) for each of N LSPs and receive a PCRpt message [RFC8231] back from PCCs. If the PST is a PCECC-SR, the PCECC will include a SID stack as per [RFC8664]. If the PST is set to \"PCECC\" type, then the PCECC will assign labels along the calculated path and set up the path by sending central controller instructions in a PCEP message to each node along the path of the LSP as per [RFC9050]. Then, the PCECC will send a PCUpd message to the ingress AGG X router with information about the new LSP. AGG X (PCC) will respond with a PCRpt with LSP status.", + "ja": "* PCECCは、N LSPのそれぞれのIngress Agg Xルーター（PCC）にPCInitiateメッセージ[RFC8281]を送信し、PCCSからPCRPTメッセージ[RFC8231]を受け取ります。PSTがPCECC-SRの場合、PCECCには[RFC8664]に従ってSIDスタックが含まれます。PSTが「PCECC」タイプに設定されている場合、PCECCは計算されたパスに沿ってラベルを割り当て、[RFC9050]に従ってLSPのパスに沿ってPCEPメッセージの中央コントローラー命令を送信してパスをセットアップします。次に、PCECCは、新しいLSPに関する情報を使用して、Ingress Agg XルーターにPCUPDメッセージを送信します。AGG X（PCC）は、LSPステータスのPCRPTで応答します。" + }, + { + "indent": 6, + "text": "* AGG X as an ingress router now has N LSPs towards AGG N and AGG N-1, which are available for installation to the router's forwarding table and for LB traffic between them. Traffic distribution between those LSPs depends on the particular realization of the hash function on that router.", + "ja": "* IngressルーターとしてのAGG Xは、Agg NおよびAgg N-1に向かってn LSPを搭載しています。これは、ルーターの転送テーブルへの取り付けとそれらの間のLBトラフィックに使用できます。これらのLSP間のトラフィック分布は、そのルーター上のハッシュ関数の特定の実現に依存します。" + }, + { + "indent": 6, + "text": "* Since the PCECC is aware of the Traffic Engineering Database (TED) (TE state) and the LSP Database (LSP-DB), it can manage and prevent possible over-subscriptions and limit the number of available load-balance states. Via a PCECC mechanism, the control can take quick actions into the network by directly provisioning the central control instructions.", + "ja": "* PCECCはトラフィックエンジニアリングデータベース（TED）（TEステート）とLSPデータベース（LSP-DB）を認識しているため、可能な過剰なサブスクリプションを管理および防止し、利用可能な負荷分散状態の数を制限できます。PCECCメカニズムを介して、コントロールは中央の制御命令を直接プロビジョニングすることにより、ネットワークに迅速なアクションを実行できます。" + }, + { + "indent": 0, + "text": "3.5. PCECC and Inter-AS TE", + "section_title": true, + "ja": "3.5. PCECCおよびINTER-AS TE" + }, + { + "indent": 3, + "text": "There are various signalling options for establishing Inter-AS TE LSPs: contiguous TE LSPs [RFC5151], stitched TE LSPs [RFC5150], and nested TE LSPs [RFC4206].", + "ja": "LSPSを確立するためのさまざまなシグナル伝達オプションがあります：連続したTe LSP [RFC5151]、ステッチされたTe LSP [RFC5150]、およびネストされたTe LSP [RFC4206]。" + }, + { + "indent": 3, + "text": "The requirements for PCE-based Inter-AS setup [RFC5376] describe the approach and PCEP functionality that is needed for establishing Inter-AS TE LSPs.", + "ja": "PCEベースのASセットアップ[RFC5376]の要件は、テープ間の確立に必要なアプローチとPCEP機能を説明しています。" + }, + { + "indent": 3, + "text": "[RFC5376] also gives an Inter-AS and Intra-AS PCE Reference Model (as shown in Figure 7) that is provided below in shortened form for the sake of simplicity.", + "ja": "[RFC5376]は、単純さのために以下に短縮された形式で提供されるPCE Inter-As-As-As-As-As-As-As-As-As-As-As-As-As-As-As-As-As-As-Asの参照モデル（図7を参照）も提供します。" + }, + { + "indent": 6, + "text": " Inter-AS Inter-AS\n PCC <-->PCE1<--------->PCE2\n :: :: ::\n :: :: ::\n R1----ASBR1====ASBR3---R3---ASBR5\n | AS1 | | PCC |\n | | | AS2 |\n R2----ASBR2====ASBR4---R4---ASBR6\n :: ::\n :: ::\nIntra-AS Intra-AS\n PCE3 PCE4", + "raw": true, + "ja": "" + }, + { + "indent": 9, + "text": "Figure 7: Shortened Form of the Inter-AS and Intra-AS PCE Reference Model", + "ja": "図7：AS間およびAS Intra-AS PCEリファレンスモデルの短縮形式" + }, + { + "indent": 3, + "text": "The PCECC belonging to the different domains can cooperate to set up Inter-AS TE LSPs. The stateful Hierarchical PCE (H-PCE) mechanism [RFC8751] could also be used to establish a per-domain PCECC LSP first. These could be stitched together to form an Inter-AS TE LSP as described in [PCE-INTERDOMAIN].", + "ja": "さまざまなドメインに属するPCECCは、協力してlspsとしてのセットアップを行うことができます。ステートフルな階層PCE（H-PCE）メカニズム[RFC8751]を使用して、最初にドメインごとのPCECC LSPを確立することもできます。これらを一緒に縫い合わせて、[PCE-interdomain]に記載されているように、lspとしています。" + }, + { + "indent": 3, + "text": "For the sake of simplicity, here the focus is on a simplified Inter-AS case when both AS1 and AS2 belong to the same service provider administration. In that case, Inter-AS and Intra-AS PCEs could be combined in one single PCE if such combined PCE performance is enough to handle the load. The PCE will require interfaces (PCEP and BGP-LS) to both domains. PCECC redundancy mechanisms are described in [RFC8283]. Thus, routers (PCCs) in AS1 and AS2 can send PCEP messages towards the same PCECC. In Figure 8, the PCECC maintains a BGP-LS session with Route Reflectors (RRs) in each AS. This allows the RRs to redistribute routes to other BGP routers (clients) without requiring a full mesh. The RRs act as a BGP-LS Propagator, and the PCECC acts as a BGP-LS Consumer [RFC9552].", + "ja": "簡単にするために、ここでは、AS1とAS2の両方が同じサービスプロバイダー管理に属している場合、単純化されたasの場合に焦点を当てています。その場合、そのような組み合わせたPCEパフォーマンスが負荷を処理するのに十分である場合、AS間およびAS Intra-AS PCEを1つのPCEで結合することができます。PCEには、両方のドメインにインターフェイス（PCEPおよびBGP-LS）が必要です。PCECC冗長性メカニズムは[RFC8283]で説明されています。したがって、AS1およびAS2のルーター（PCC）は、同じPCECCにPCEPメッセージを送信できます。図8では、PCECCはそれぞれのASにルートリフレクター（RRS）を使用したBGP-LSセッションを維持しています。これにより、RRSは完全なメッシュを必要とせずに他のBGPルーター（クライアント）にルートを再分配できます。RRSはBGP-LSプロパゲーターとして機能し、PCECCはBGP-LS消費者[RFC9552]として機能します。" + }, + { + "indent": 7, + "text": " +----BGP-LS------+ +------BGP-LS-----+\n | | | |\n +-PCEP-|----++-+-------PCECC-----PCEP--++-+-|-------+\n+-:------|----::-:-+ +--::-:-|-------:---+\n| : | :: : | | :: : | : |\n| : RR1 :: : | | :: : RR2 : |\n| v v: : | LSP1 | :: v v |\n| R1---------ASBR1=======================ASBR3--------R3 |\n| | v : | | :v | |\n| +----------ASBR2=======================ASBR4---------+ |\n| | Region 1 : | | : Region 1 | |\n|----------------:-| |--:-------------|--|\n| | v | LSP2 | v | |\n| +----------ASBR5=======================ASBR6---------+ |\n| Region 2 | | Region 2 |\n+------------------+ <--------------> +-------------------+\n MPLS Domain 1 Inter-AS MPLS Domain 2\n<=======AS1=======> <========AS2=======>", + "raw": true, + "ja": "" + }, + { + "indent": 17, + "text": "Figure 8: Particular Case of Inter-AS PCE", + "ja": "図8：PCE間の特定のケース" + }, + { + "indent": 3, + "text": "In the case of the PCECC Inter-AS TE scenario (as shown in Figure 8), where the service provider controls both domains (AS1 and AS2), each of them has its own IGP and MPLS transport. There is a need to set up Inter-AS LSPs for transporting different services on top of them (such as Voice, L3VPN, etc.). Inter-AS links with different capacities exist in several regions. The task is not only to provision those Inter-AS LSPs with given constraints but also to calculate the path and pre-setup the backup Inter-AS LSPs that will be used if the primary LSP fails.", + "ja": "PCECC Inter-AS TEシナリオ（図8に示すように）の場合、サービスプロバイダーは両方のドメイン（AS1とAS2）を制御します。それぞれが独自のIGPおよびMPLSトランスポートを備えています。それらの上にさまざまなサービスを輸送するために、LSP間（音声、L3VPNなど）を設定する必要があります。さまざまな容量を持つリンクをいくつかの地域に存在します。タスクは、それらのLSPを指定された制約で提供するだけでなく、パスを計算して、プライマリLSPが故障した場合に使用されるLSPとしてのバックアップ間局を事前に設定することでもあります。" + }, + { + "indent": 3, + "text": "As per Figure 8, LSP1 from R1 to R3 goes via ASBR1 and ASBR3, and it is the primary Inter-AS LSP. LSP2 from R1 to R3 that goes via ASBR5 and ASBR6 is the backup one. In addition, there could also be a bypass LSP setup to protect against ASBR or Inter-AS link failures.", + "ja": "図8によると、R1からR3へのLSP1はASBR1およびASBR3を介して進み、LSPとしての主要なものです。R1からR3へのLSP2はASBR5を介してasbr6を介してバックアップされています。さらに、ASBRまたはAS間のリンク障害から保護するためのバイパスLSPセットアップもある可能性があります。" + }, + { + "indent": 3, + "text": "After the addition of PCECC functionality to the PCE (SDN controller), the PCECC-based Inter-AS TE model should follow the PCECC use case for TE LSP including the requirements described in [RFC5376] with the following details:", + "ja": "PCE（SDNコントローラー）にPCECC機能を追加した後、PCECCベースのTE TEモデルは、[RFC5376]に記載されている要件を含むTE LSPのPCECCユースケースに次の詳細を含めて従う必要があります。" + }, + { + "indent": 6, + "text": "* Since the PCECC needs to know the topology of both domains AS1 and AS2, the PCECC can utilize the BGP-LS peering with BGP routers (or RRs) in both domains.", + "ja": "* PCECCは両方のドメインAS1とAS2のトポロジーを知る必要があるため、PCECCは両方のドメインでBGPルーター（またはRRS）を使用してBGP-LSピアリングを利用できます。" + }, + { + "indent": 6, + "text": "* The PCECC needs to establish PCEP connectivity with all routers in both domains (see also Section 4 of [RFC5376]).", + "ja": "* PCECCは、両方のドメインのすべてのルーターでPCEP接続を確立する必要があります（[RFC5376]のセクション4も参照）。" + }, + { + "indent": 6, + "text": "* After the operator's application or service orchestrator creates a request for tunnel creation of a specific service, the PCECC will receive that request via the Northbound Interface (NBI) (note that the NBI type is implementation-dependent; it could be NETCONF/ YANG, REST, etc.). Then, the PCECC will calculate the optimal path based on the OF and given constraints (i.e., PST, BW, etc.). These constraints include those from [RFC5376], such as priority, AS sequence, preferred ASBR, disjoint paths, and protection type. In this step, we will have two paths: \"R1-ASBR1-ASBR3-R3, R1-ASBR5-ASBR6-R3\".", + "ja": "* オペレーターのアプリケーションまたはサービスオーケストレーターが特定のサービスのトンネル作成のリクエストを作成した後、PCECCはノースバウンドインターフェイス（NBI）を介してそのリクエストを受け取ります（NBIタイプは実装依存であることに注意してください。、など）。次に、PCECCは、ofおよび与えられた制約に基づいて最適なパスを計算します（つまり、PST、BWなど）。これらの制約には、優先度など、[RFC5376]の[RFC5376]の制約、優先ASBR、馬鹿げたパス、保護タイプなどが含まれます。このステップでは、「R1-ASBR1-ASBR3-R3、R1-ASBR5-ASBR6-R3」という2つのパスがあります。" + }, + { + "indent": 6, + "text": "* The PCECC will use central control download instructions to the PCC based on the PST. At this stage, it is assumed the PCECC is aware of the label space it controls, and in the case of SR, the SID allocation and distribution is already done.", + "ja": "* PCECCは、PSTに基づいてPCCにCentral Controlのダウンロード命令を使用します。この段階では、PCECCが制御するラベル空間を認識していると想定されており、SRの場合、SIDの割り当てと分布はすでに行われています。" + }, + { + "indent": 6, + "text": "* The PCECC will send a PCInitiate message [RFC8281] towards the ingress router R1 (PCC) in AS1 and receive the PCRpt message [RFC8231] back from it.", + "ja": "* PCECCは、AS1のIngressルーターR1（PCC）にPCInitiateメッセージ[RFC8281]を送信し、PCRPTメッセージ[RFC8231]を受け取ります。" + }, + { + "indent": 12, + "text": "- If the PST is SR-MPLS, the PCECC will include the SID stack as per [RFC8664]. Optionally, a BSID or BGP Peering-SID [RFC9087] can also be included on the AS boundary. The backup SID stack can be installed at ingress R1, but more importantly, each node along the SR path could also do the local protection just based on the top segment.", + "ja": "- PSTがSR-MPLSの場合、PCECCには[RFC8664]に従ってSIDスタックが含まれます。オプションで、BSIDまたはBGP Peering-SID [RFC9087]もAS境界に含めることができます。バックアップSIDスタックはIngress R1にインストールできますが、さらに重要なことに、SRパスに沿った各ノードは、上部セグメントだけに基づいてローカル保護を行うこともできます。" + }, + { + "indent": 12, + "text": "- If the PST is a PCECC, the PCECC will assign labels along the calculated paths (\"R1-ASBR1-ASBR3-R3\", \"R1-ASBR5-ASBR6-R3\") and sets up the path by sending central controller instructions in a PCEP message to each node along the path of the LSPs as per [RFC9050]. After these steps, the PCECC will send a PCUpd message to the ingress R1 router with information about new LSPs and R1 will respond by a PCRpt with LSP(s) status.", + "ja": "- PSTがPCECCの場合、PCECCは計算されたパスに沿ってラベルを割り当てます（ \"R1-ASBR1-ASBR3-R3\"、 \"R1-ASBR5-ASBR6-R3\"）。[RFC9050]に従って、LSPのパスに沿った各ノードへのメッセージ。これらの手順の後、PCECCは新しいLSPに関する情報を使用してPCUPDメッセージをIngress R1ルーターに送信し、R1はLSP（S）ステータスのPCRPTで応答します。" + }, + { + "indent": 6, + "text": "* After that step, R1 now has primary and backup TEs (LSP1 and LSP2) towards R3. It is up to the router implementation for how to switchover to backup LSP2 if LSP1 fails.", + "ja": "* そのステップの後、R1にはR3に向かってプライマリおよびバックアップTE（LSP1およびLSP2）があります。LSP1が失敗した場合、LSP2をバックアップする方法のルーターの実装次第です。" + }, + { + "indent": 0, + "text": "3.6. PCECC for Multicast LSPs", + "section_title": true, + "ja": "3.6. マルチキャストLSPのPCECC" + }, + { + "indent": 3, + "text": "The multicast LSPs can be set up via the RSVP-TE P2MP or Multipoint LDP (mLDP) protocols. The setup of these LSPs may require manual configurations and complex signalling when the protection is considered. By using the PCECC solution, the multicast LSP can be computed and set up through a centralized controller that has the full picture of the topology and BW usage for each link. It not only reduces the complex configurations comparing the distributed RSVP-TE P2MP or mLDP signalling, but also it can compute the disjoint primary path and secondary P2MP path efficiently.", + "ja": "マルチキャストLSPは、RSVP-TE P2MPまたはマルチポイントLDP（MLDP）プロトコルを介してセットアップできます。これらのLSPのセットアップでは、保護を考慮した場合、手動構成と複雑なシグナル伝達が必要になる場合があります。PCECCソリューションを使用することにより、マルチキャストLSPを計算して、各リンクのトポロジとBW使用の全体像を備えた集中コントローラーを介してセットアップできます。分散型RSVP-TE P2MPまたはMLDPシグナルを比較する複雑な構成を減らすだけでなく、馬鹿げたプライマリパスとセカンダリP2MPパスを効率的に計算することもできます。" + }, + { + "indent": 0, + "text": "3.6.1. PCECC for the Setup of P2MP/MP2MP LSPs", + "section_title": true, + "ja": "3.6.1. P2MP/MP2MP LSPのセットアップ用PCECC" + }, + { + "indent": 3, + "text": "It is assumed the PCECC is aware of the label space it controls for all nodes and makes allocations accordingly.", + "ja": "PCECCは、すべてのノードに対して制御するラベルスペースを認識しており、それに応じて割り当てを行うと想定されています。" + }, + { + "indent": 11, + "text": " +----------+\n | R1 | Root Node of the multicast LSP\n +----------+\n |9000 (link0)\n +----------+\nTransit Node | R2 |\nbranch +----------+\n * | * *\n 9001* | * *9002\n link1 * | * *link2\n+-----------+ | * +-----------+\n| R4 | | * | R5 | Transit Nodes\n+-----------+ | * +-----------+\n * | * * +\n 9003* | * * +9004\n link3 * | * * +link4\n +-----------+ +-----------+\n | R3 | | R6 | Leaf Node\n +-----------+ +-----------+\n 9005| link5\n +-----------+\n | R8 | Leaf Node\n +-----------+", + "raw": true, + "ja": "" + }, + { + "indent": 10, + "text": "Figure 9: Using a PCECC for the Setup of P2MP/MP2MP LSPs", + "ja": "図9：P2MP/MP2MP LSPのセットアップにPCECCを使用する" + }, + { + "indent": 3, + "text": "The P2MP examples (based on Figure 9) are explained here, where R1 is the root and the routers R8 and R6 are the leaves.", + "ja": "P2MPの例（図9に基づく）はここで説明されています。ここで、R1はルートであり、ルーターR8とR6は葉です。" + }, + { + "indent": 6, + "text": "* Based on the P2MP path computation request/delegation or PCE initiation, the PCECC receives the request with constraints and optimization criteria.", + "ja": "* P2MPパス計算要求/委任またはPCEの開始に基づいて、PCECCは制約と最適化基準でリクエストを受信します。" + }, + { + "indent": 6, + "text": "* The PCECC will calculate the optimal P2MP path according to given constraints (i.e., BW).", + "ja": "* PCECCは、指定された制約（つまり、BW）に従って最適なP2MPパスを計算します。" + }, + { + "indent": 6, + "text": "* The PCECC will provision each node along the path and assign incoming and outgoing labels from R1 to {R6, R8} with the path as \"R1-link0-R2-link2-R5-link4-R6\" and \"R1-link0-R2-link1-R4-link3-R3-link5-R8\":", + "ja": "* PCECCは、パスに沿って各ノードをプロビジョニングし、R1から{R6、R8}に着信ラベルと発信ラベルを「R1-Link0-R2-Link2-Link4-R6」および「R1-Link0-R2-を割り当てます。Link1-R4-Link3-R3-Link5-R8 \"：" + }, + { + "indent": 12, + "text": "- R1: Outgoing label 9000 on link0", + "ja": "- R1：Link0の発信ラベル9000" + }, + { + "indent": 12, + "text": "- R2: Incoming label 9000 on link0", + "ja": "- R2：Link0の着信ラベル9000" + }, + { + "indent": 12, + "text": "- R2: Outgoing label 9001 on link1 (*)", + "ja": "- R2：link1の発信ラベル9001（*）" + }, + { + "indent": 12, + "text": "- R2: Outgoing label 9002 on link2 (*)", + "ja": "- R2：link2の発信ラベル9002（*）" + }, + { + "indent": 12, + "text": "- R5: Incoming label 9002 on link2", + "ja": "- R5：リンク2の着信ラベル9002" + }, + { + "indent": 12, + "text": "- R5: Outgoing label 9004 on link4", + "ja": "- R5：リンク4の発信ラベル9004" + }, + { + "indent": 12, + "text": "- R6: Incoming label 9004 on link4", + "ja": "- R6：リンク4の着信ラベル9004" + }, + { + "indent": 12, + "text": "- R4: Incoming label 9001 on link1", + "ja": "- R4：リンク1の着信ラベル9001" + }, + { + "indent": 12, + "text": "- R4: Outgoing label 9003 on link3", + "ja": "- R4：リンク3の発信ラベル9003" + }, + { + "indent": 12, + "text": "- R3: Incoming label 9003 on link3", + "ja": "- R3：リンク3の着信ラベル9003" + }, + { + "indent": 12, + "text": "- R3: Outgoing label 9005 on link5", + "ja": "- R3：リンク5の発信ラベル9005" + }, + { + "indent": 12, + "text": "- R8: Incoming label 9005 on link5", + "ja": "- R8：リンク5の着信ラベル9005" + }, + { + "indent": 6, + "text": "* This can also be represented as: {R1, 6000}, {6000, R2, {9001, 9002}}, {9001, R4, 9003}, {9002, R5, 9004} {9003, R3, 9005}, {9004, R6}, {9005, R8}. The main difference (*) is in the branch node instruction at R2, where two copies of a packet are sent towards R4 and R5 with 9001 and 9002 labels, respectively.", + "ja": "* これは、{r1、6000}、{6000、r2、{9001、9002}}、{9001、r4、9003}、{9002、r5、9004} {9003、r3、9005}、{9004、r6}、{9005、r8}。主な違い（*）は、R2のブランチノード命令で、パケットの2つのコピーがそれぞれ9001と9002のラベルでR4とR5に送られます。" + }, + { + "indent": 3, + "text": "The packet forwarding involves the following:", + "ja": "パケット転送には次のものが含まれます。" + }, + { + "indent": 18, + "text": "Step 1. R1 sends a packet to R2 simply by pushing the label of 9000 to the packet.", + "ja": "ステップ1。R19000のラベルをパケットに押し込むだけで、パケットをR2に送信します。" + }, + { + "indent": 18, + "text": "Step 2. When R2 receives the packet with label 9000, it will forward it to R4 by swapping label 9000 to 9001. At the same time, it will replicate the packet and swap the label 9000 to 9002 and forward it to R5.", + "ja": "ステップ2。R2がラベル9000でパケットを受信すると、ラベル9000から9001を交換してR4に転送します。同時に、パケットを複製し、ラベル9000から9002に交換し、R5に転送します。" + }, + { + "indent": 18, + "text": "Step 3. When R4 receives the packet with label 9001, it will forward it to R3 by swapping 9001 to 9003. When R5 receives the packet with the label 9002, it will forward it to R6 by swapping 9002 to 9004.", + "ja": "ステップ3。R4がラベル9001でパケットを受信すると、9001を交換してR3に転送します。R5がラベル9002でパケットを受信すると、9002を交換してR6に転送します。" + }, + { + "indent": 18, + "text": "Step 4. When R3 receives the packet with label 9003, it will forward it to R8 by swapping it to 9005. When R5 receives the packet with label 9002, it will be swapped to 9004 and sent to R6.", + "ja": "ステップ4。R3がラベル9003でパケットを受信すると、R8を9005に交換してR8に転送します。R5がラベル9002でパケットを受信すると、9004に交換され、R6に送信されます。" + }, + { + "indent": 18, + "text": "Step 5. When R8 receives the packet with label 9005, it will pop the label. When R6 receives the packet with label 9004, it will pop the label.", + "ja": "ステップ5。R8がラベル9005でパケットを受信すると、ラベルがポップされます。R6がラベル9004でパケットを受信すると、ラベルがポップされます。" + }, + { + "indent": 0, + "text": "3.6.2. PCECC for the End-to-End Protection of P2MP/MP2MP LSPs", + "section_title": true, + "ja": "3.6.2. P2MP/MP2MP LSPのエンドツーエンド保護のためのPCECC" + }, + { + "indent": 3, + "text": "This section describes the end-to-end managed path protection service as well as the local protection with the operation management in the PCECC network for the P2MP/MP2MP LSP.", + "ja": "このセクションでは、エンドツーエンドのマネージドパス保護サービスと、P2MP/MP2MP LSPのPCECCネットワークの操作管理を伴うローカル保護について説明します。" + }, + { + "indent": 3, + "text": "An end-to-end protection principle can be applied for computing backup P2MP or MP2MP LSPs. During the computation of the primary multicast trees, the PCECC could also take the computation of a secondary tree into consideration. A PCECC could compute the primary and backup P2MP (or MP2MP) LSPs together or sequentially.", + "ja": "バックアップP2MPまたはMP2MP LSPを計算するために、エンドツーエンドの保護原理を適用できます。プライマリマルチキャストツリーの計算中、PCECCは二次ツリーの計算を考慮に入れることもできます。PCECCは、プライマリおよびバックアップP2MP（またはMP2MP）LSPを一緒にまたは順次計算できます。" + }, + { + "indent": 8, + "text": " +----+ +----+\n Root Node of LSP | R1 |--| R11|\n +----+ +----+\n / +\n 10/ +20\n / +\n +----------+ +-----------+\nTransit Node | R2 | | R3 |\n +----------+ +-----------+\n | \\ + +\n | \\ + +\n 10| 10\\ +20 20+\n | \\ + +\n | \\ +\n | + \\ +\n +-----------+ +-----------+ Leaf Nodes\n | R4 | | R5 | (Downstream LSR)\n +-----------+ +-----------+", + "raw": true, + "ja": "" + }, + { + "indent": 5, + "text": "Figure 10: PCECC for the End-to-End Protection of P2MP/MP2MP LSPs", + "ja": "図10：P2MP/MP2MP LSPのエンドツーエンド保護のためのPCECC" + }, + { + "indent": 3, + "text": "In Figure 10, when the PCECC sets up the primary multicast tree from the root node R1 to the leaves, which is R1->R2->{R4, R5}, it can set up the backup tree at the same time, which is R1->R11->R3->{R4, R5}. Both of them (the primary forwarding tree and secondary forwarding tree) will be downloaded to each router along the primary path and the secondary path. The traffic will be forwarded through the R1->R2->{R4, R5} path normally, but when a node in the primary tree fails (say R2), the root node R1 will switch the flow to the backup tree, which is R1->R11->R3->{R4, R5}. By using the PCECC, path computation, label downloading, and finally forwarding can be done without the complex signalling used in the P2MP RSVP-TE or mLDP.", + "ja": "図10では、PCECCがルートノードR1から葉、つまりR1-> {r4、R5}のプライマリマルチキャストツリーをセットアップすると、バックアップツリーを同時にセットアップできます。r1-> r11-> r3-> {r4、r5}。両方（主要な転送ツリーとセカンダリ転送ツリー）は、プライマリパスとセカンダリパスに沿って各ルーターにダウンロードされます。トラフィックはR1-> R2-> {r4、R5}パスを介して正常に転送されますが、プライマリツリーのノードが失敗すると（たとえばR2）、ルートノードR1はフローをバックアップツリーに切り替えます。r1-> r11-> r3-> {r4、r5}。PCECC、PATH計算、ラベルのダウンロード、および最終的に転送を使用することにより、P2MP RSVP-TEまたはMLDPで使用される複雑なシグナルを使用せずに実行できます。" + }, + { + "indent": 0, + "text": "3.6.3. PCECC for the Local Protection of P2MP/MP2MP LSPs", + "section_title": true, + "ja": "3.6.3. P2MP/MP2MP LSPの局所保護のためのPCECC" + }, + { + "indent": 3, + "text": "In this section, we describe the local protection service in the PCECC network for the P2MP/MP2MP LSP.", + "ja": "このセクションでは、P2MP/MP2MP LSPのPCECCネットワークのローカル保護サービスについて説明します。" + }, + { + "indent": 3, + "text": "While the PCECC sets up the primary multicast tree, it can also build the backup LSP between the Point of Local Repair (PLR), protected node, and Merge Points (MPs) (the downstream nodes of the protected node). In the cases where the amount of downstream nodes is huge, this mechanism can avoid unnecessary packet duplication on the PLR and protect the network from traffic congestion risks.", + "ja": "PCECCはプライマリマルチキャストツリーをセットアップしますが、ローカル修理ポイント（PLR）、保護ノード、マージポイント（MPS）（保護ノードの下流ノード）の間にバックアップLSPを構築することもできます。ダウンストリームノードの量が膨大な場合、このメカニズムはPLRの不必要なパケットの複製を回避し、交通渋滞のリスクからネットワークを保護することができます。" + }, + { + "indent": 8, + "text": " +------------+\n | R1 | Root Node\n +------------+\n .\n .\n .\n +------------+ Point of Local Repair /\n | R10 | Switchover Point\n +------------+ (Upstream LSR)\n / +\n 10/ +20\n / +\n +----------+ +-----------+\nProtected Node | R20 | | R30 |\n +----------+ +-----------+\n | \\ + +\n | \\ + +\n 10| 10\\ +20 20+\n | \\ + +\n | \\ +\n | + \\ +\n +-----------+ +-----------+ Merge Point\n | R40 | | R50 | (Downstream LSR)\n +-----------+ +-----------+\n . .\n . .", + "raw": true, + "ja": "" + }, + { + "indent": 8, + "text": "Figure 11: PCECC for the Local Protection of P2MP/MP2MP LSPs", + "ja": "図11：P2MP/MP2MP LSPの局所保護のためのPCECC" + }, + { + "indent": 3, + "text": "In Figure 11, when the PCECC sets up the primary multicast path around the PLR node R10 to protect node R20, which is R10->R20->{R40, R50}, it can set up the backup path R10->R30->{R40, R50} at the same time. Both the primary forwarding path and the secondary bypass forwarding path will be downloaded to each router along the primary path and the secondary bypass path. The traffic will be forwarded through the R10->R20->{R40, R50} path normally, and when there is a node failure for node R20, the PLR node R10 will switch the flow to the backup path, which is R10->R30->{R40, R50}. By using the PCECC, path computation, label downloading, and finally forwarding can be done without the complex signalling used in the P2MP RSVP-TE or mLDP.", + "ja": "図11では、PCECCがPLRノードR10の周りのプライマリマルチキャストパスを設定して、r10-> r20-> {r40、r50}です。バックアップパスr10-> r30->{r40、r50}同時に。一次転送パスとセカンダリバイパス転送パスの両方が、プライマリパスとセカンダリバイパスパスに沿った各ルーターにダウンロードされます。トラフィックはR10-> R20-> {R40、R50}パスを介して正常に転送され、ノードR20にノード障害がある場合、PLRノードR10はフローをバックアップパスに切り替えます。r30-> {r40、r50}。PCECC、PATH計算、ラベルのダウンロード、および最終的に転送を使用することにより、P2MP RSVP-TEまたはMLDPで使用される複雑なシグナルを使用せずに実行できます。" + }, + { + "indent": 0, + "text": "3.7. PCECC for Traffic Classification", + "section_title": true, + "ja": "3.7. トラフィック分類のためのPCECC" + }, + { + "indent": 3, + "text": "As described in [RFC8283], traffic classification is an important part of traffic engineering. It is the process of looking into a packet to determine how it should be treated while it is forwarded through the network. It applies in many scenarios, including the following:", + "ja": "[RFC8283]で説明されているように、トラフィック分類はトラフィックエンジニアリングの重要な部分です。これは、ネットワークを介して転送されたときにどのように処理するかを決定するためにパケットを調べるプロセスです。以下を含む多くのシナリオに適用されます。" + }, + { + "indent": 6, + "text": "* MPLS traffic engineering (where it determines what traffic is forwarded into which LSPs),", + "ja": "* MPLSトラフィックエンジニアリング（LSPにどのトラフィックが転送されるかを決定する場所）、" + }, + { + "indent": 6, + "text": "* SR (where it is used to select which set of forwarding instructions (SIDs) to add to a packet), and", + "ja": "* SR（パケットに追加する転送命令のセット（SIDS）を選択するために使用される場合）、および" + }, + { + "indent": 6, + "text": "* SFC (where it indicates how a packet should be forwarded across which service function path).", + "ja": "* SFC（ここで、パケットがどのサービス機能パスを越えて転送するかを示します）。" + }, + { + "indent": 3, + "text": "In conjunction with traffic engineering, traffic classification is an important enabler for LB. Traffic classification is closely linked to the computational elements of planning for the network functions because it determines how traffic is balanced and distributed through the network. Therefore, selecting what traffic classification mechanism should be performed by a router is an important part of the work done by a PCECC.", + "ja": "交通工学と併せて、トラフィック分類はLBにとって重要なイネーブラーです。トラフィックの分類は、ネットワークを介してトラフィックのバランスと分布の方法を決定するため、ネットワーク機能の計画の計算要素に密接にリンクしています。したがって、ルーターによって実行されるトラフィック分類メカニズムを選択することは、PCECCによって行われた作業の重要な部分です。" + }, + { + "indent": 3, + "text": "The description of traffic flows by the combination of multiple Flow Specification components and their dissemination as traffic Flow Specifications is described for BGP in [RFC8955]. When a PCECC is used to initiate tunnels (such as TE LSPs or SR paths) using PCEP, it is important that the headend of the tunnels understands what traffic to place on each tunnel. [RFC9168] specifies a set of extensions to PCEP to support the dissemination of Flow Specification components where the instructions are passed from the PCECC to the routers using PCEP.", + "ja": "複数のフロー仕様コンポーネントの組み合わせと交通流の仕様としての普及によるトラフィックフローの説明は、[RFC8955]のBGPについて説明されています。PCEPを使用してPCECCを使用してトンネル（TE LSPやSRパスなど）を開始する場合、トンネルのヘッドエンドが各トンネルに配置するトラフィックを理解することが重要です。[RFC9168]は、PCEPを使用してPCECCからルーターに命令が渡されるフロー仕様コンポーネントの普及をサポートするために、PCEPの拡張セットを指定します。" + }, + { + "indent": 3, + "text": "Along with traffic classification, there are a few more questions about the tunnels set up by the PCECC that need to be considered:", + "ja": "トラフィック分類に加えて、PCECCによって設定されたトンネルについて、考慮する必要があるトンネルについてさらにいくつかの質問があります。" + }, + { + "indent": 6, + "text": "* how to use it,", + "ja": "* それを使用する方法、" + }, + { + "indent": 6, + "text": "* whether it is a virtual link,", + "ja": "* 仮想リンクかどうか、" + }, + { + "indent": 6, + "text": "* whether to advertise it in the IGP as a virtual link, and", + "ja": "* IGPで仮想リンクとして宣伝するかどうか、そして" + }, + { + "indent": 6, + "text": "* what bits of this information to signal to the tail end.", + "ja": "* この情報のビットは、テールエンドに合図します。" + }, + { + "indent": 3, + "text": "These are out of the scope of this document.", + "ja": "これらはこのドキュメントの範囲外です。" + }, + { + "indent": 0, + "text": "3.8. PCECC for SFC", + "section_title": true, + "ja": "3.8. SFCのPCECC" + }, + { + "indent": 3, + "text": "Service Function Chaining (SFC) is described in [RFC7665]. It is the process of directing traffic in a network such that it passes through specific hardware devices or virtual machines (known as service function nodes) that can perform particular desired functions on the traffic. The set of functions to be performed and the order in which they are to be performed is known as a service function chain. The chain is enhanced with the locations at which the service functions are to be performed to derive a Service Function Path (SFP). Each packet is marked as belonging to a specific SFP, and that marking lets each successive service function node know which functions to perform and to which service function node to send the packet next. To operate an SFC network, the service function nodes must be configured to understand the packet markings, and the edge nodes must be told how to mark packets entering the network. Additionally, it may be necessary to establish tunnels between service function nodes to carry the traffic. Planning an SFC network requires LB between service function nodes and traffic engineering across the network that connects them. As per [RFC8283], these are operations that can be performed by a PCECC, and that controller can use PCEP to program the network and install the service function chains and any required tunnels.", + "ja": "サービス関数チェーン（SFC）は[RFC7665]で説明されています。これは、トラフィックで特定の目的の機能を実行できる特定のハードウェアデバイスまたは仮想マシン（サービス関数ノードとして知られている）を通過するように、ネットワーク内のトラフィックを向けるプロセスです。実行される関数のセットとそれらが実行される順序は、サービス関数チェーンとして知られています。チェーンは、サービス関数パス（SFP）を導出するためにサービス機能を実行する場所で強化されます。各パケットは特定のSFPに属するものとしてマークされており、そのマーキングにより、各連続するサービス機能ノードが実行する機能と、次にパケットを送信するサービス機能ノードを知ることができます。SFCネットワークを操作するには、パケットマークを理解するようにサービス関数ノードを構成する必要があり、エッジノードにネットワークに入るパケットをマークする方法を指定する必要があります。さらに、トラフィックを運ぶためにサービス関数ノード間にトンネルを確立する必要がある場合があります。SFCネットワークの計画には、サービス機能ノードとそれらを接続するネットワーク全体のトラフィックエンジニアリングの間のLBが必要です。[RFC8283]によると、これらはPCECCで実行できる操作であり、コントローラーはPCEPを使用してネットワークをプログラムし、サービス関数チェーンと必要なトンネルをインストールできます。" + }, + { + "indent": 3, + "text": "A possible mechanism could add support for SFC-based central control instructions. The PCECC will be able to instruct each Service Function Forwarder (SFF) along the SFP.", + "ja": "考えられるメカニズムは、SFCベースの中央制御命令のサポートを追加できます。PCECCは、SFPに沿って各Service Function Forwarder（SFF）を指示することができます。" + }, + { + "indent": 6, + "text": "* Service Path Identifier (SPI): Uniquely identifies an SFP.", + "ja": "* サービスパス識別子（SPI）：SFPを一意に識別します。" + }, + { + "indent": 6, + "text": "* Service Index (SI): Provides location within the SFP.", + "ja": "* サービスインデックス（SI）：SFP内の場所を提供します。" + }, + { + "indent": 6, + "text": "* Provide SFC Proxy handling instruction.", + "ja": "* SFCプロキシ処理命令を提供します。" + }, + { + "indent": 3, + "text": "The PCECC can play the role of setting the traffic classification rules (as per Section 3.7) at the classifier to impose the Network Service Header (NSH) [RFC8300]. It can also download the forwarding instructions to each SFF along the way so that they could process the NSH and forward accordingly. This includes instructions for the service classifier that handles the context header, metadata, etc. This metadata/context is shared amongst SFs and classifiers, between SFs, and between external systems (such as a PCECC) and SFs. As described in [RFC7665], the SFC encapsulation enables the sharing of metadata/context information along the SFP.", + "ja": "PCECCは、ネットワークサービスヘッダー（NSH）[RFC8300]を課すために、分類器にトラフィック分類ルール（セクション3.7に従って）を設定する役割を果たすことができます。また、途中で各SFFへの転送命令をダウンロードして、NSHを処理してそれに応じて転送できるようにすることもできます。これには、コンテキストヘッダー、メタデータなどを処理するサービス分類器の指示が含まれます。このメタデータ/コンテキストは、SFSおよび分類器間、SFS間、および外部システム（PCECCなど）およびSFS間で共有されます。[RFC7665]で説明されているように、SFCカプセル化により、SFPに沿ったメタデータ/コンテキスト情報の共有が可能になります。" + }, + { + "indent": 3, + "text": "It is also possible to support SFC with SR in conjunction with or without an NSH such as described in [RFC9491] and [SR-SERVICE]. PCECC techniques can also be used for service-function-related segments and SR service policies.", + "ja": "また、[RFC9491]および[SR-Service]に記載されているようなNSHの有無にかかわらず、SRをSRでサポートすることも可能です。PCECCテクニックは、サービス機能関連のセグメントやSRサービスポリシーにも使用できます。" + }, + { + "indent": 0, + "text": "3.9. PCECC for Native IP", + "section_title": true, + "ja": "3.9. ネイティブIP用のPCECC" + }, + { + "indent": 3, + "text": "[RFC8735] describes the scenarios and simulation results for the \"Centralized Control Dynamic Routing (CCDR)\" solution, which integrates the advantage of using distributed protocols (IGP/BGP) and the power of a centralized control technology (PCE/SDN), providing traffic engineering for native IP networks. [RFC8821] defines the framework for CCDR traffic engineering within a native IP network, using multiple BGP sessions and a PCE as the centralized controller. It requires the PCECC to send the instructions to the PCCs to build multiple BGP sessions, distribute different prefixes on the established BGP sessions, and assign the different paths to the BGP next hops. The PCEP is used to transfer the key parameters between the PCE and the underlying network devices (PCC) using the PCECC technique. The central control instructions from the PCECC to PCC will identify which prefix should be advertised on which BGP session. There are PCEP extensions defined in [PCEP-NATIVE] for it.", + "ja": "[RFC8735]は、分布プロトコル（IGP/BGP）を使用する利点と集中制御技術（PCE/SDN）の能力を統合し、提供し、提供する、「集中制御動的ルーティング（CCDR）」ソリューションのシナリオとシミュレーション結果を説明します。ネイティブIPネットワークのトラフィックエンジニアリング。[RFC8821]は、複数のBGPセッションとPCEを中央コントローラーとして使用して、ネイティブIPネットワーク内のCCDRトラフィックエンジニアリングのフレームワークを定義します。PCECCは、複数のBGPセッションを構築し、確立されたBGPセッションで異なるプレフィックスを配布し、BGPの次のホップに異なるパスを割り当てるために、PCCSに指示を送信する必要があります。PCEPは、PCECC技術を使用して、PCEと基礎となるネットワークデバイス（PCC）の間に重要なパラメーターを転送するために使用されます。PCECCからPCCへの中央制御命令は、どのBGPセッションでどのプレフィックスを宣伝するかを特定します。[pcep-native]で定義されているPCEP拡張機能があります。" + }, + { + "indent": 3, + "text": " +------+\n +----------+ PCECC+-------+\n | +------+ |\n | |\n PCEP | BGP Session 1(lo11/lo21)| PCEP\n +-------------------------+\n | |\n | BGP Session 2(lo12/lo22)|\n +-------------------------+\nPF12 | | PF22\nPF11 | | PF21\n+---+ +-----+-----+ +-----+-----+ +---+\n|SW1+---------+(lo11/lo12)+-------------+(lo21/lo22)+-----------+SW2|\n+---+ | R1 +-------------+ R2 | +---+\n +-----------+ +-----------+", + "raw": true, + "ja": "" + }, + { + "indent": 23, + "text": "Figure 12: PCECC for Native IP", + "ja": "図12：ネイティブIPのPCECC" + }, + { + "indent": 3, + "text": "In the case as shown in Figure 12, the PCECC will instruct both R1 and R2 how to form BGP sessions with each other via PCEP and which IP prefixes need to be advertised via which BGP session.", + "ja": "図12に示すように、PCECCはR1とR2の両方に、PCEPを介してBGPセッションを互いに形成する方法と、どのBGPセッションを介して宣伝する必要があるかを指示します。" + }, + { + "indent": 0, + "text": "3.10. PCECC for BIER", + "section_title": true, + "ja": "3.10. ビア用PCECC" + }, + { + "indent": 3, + "text": "Bit Index Explicit Replication (BIER) [RFC8279] defines an architecture where all intended multicast receivers are encoded as a BitMask in the multicast packet header within different encapsulations. A router that receives such a packet will forward that packet based on the bit position in the packet header towards the receiver(s) following a precomputed tree for each of the bits in the packet. Each receiver is represented by a unique bit in the BitMask.", + "ja": "ビットインデックス明示的複製（BIER）[RFC8279]は、さまざまなカプセル内のマルチキャストパケットヘッダーのビットマスクとしてエンコードされるすべてのマルチキャストレシーバーがエンコードされるアーキテクチャを定義します。このようなパケットを受信するルーターは、パケットヘッダー内のビット位置に基づいてパケットを転送し、パケット内の各ビットの事前計算ツリーに続いてレシーバーに向かって進みます。各レシーバーは、ビットマスクのユニークなビットで表されます。" + }, + { + "indent": 3, + "text": "BIER-TE [RFC9262] shares architecture and packet formats with BIER. BIER-TE forwards and replicates packets based on a BitString in the packet header, but every BitPosition of the BitString of a BIER-TE packet indicates one or more adjacencies. BIER-TE paths can be derived from a PCE and used at the ingress (a possible mechanism is described in [PCEP-BIER]).", + "ja": "Bier-TE [RFC9262]は、Bierとアーキテクチャとパケット形式を共有しています。パケットヘッダーのビットストリングに基づいて、ビアテをフォワードして再現しますが、ビアテパケットのビットストリングのすべてのビットポジションは、1つ以上の隣接を示します。Bier-TEパスはPCEから導出され、イングレスで使用できます（可能なメカニズムは[PCEP-Bier]で説明されています）。" + }, + { + "indent": 3, + "text": "The PCECC mechanism could be used for the allocation of bits for the BIER router for BIER as well as for the adjacencies for BIER-TE. PCECC-based controllers can use PCEP to instruct the BIER-capable routers on the meaning of the bits as well as other fields needed for BIER encapsulation. The PCECC could be used to program the BIER router with various parameters used in the BIER encapsulation (such as BIER sub-domain-id, BFR-id, etc.) for both node and adjacency.", + "ja": "PCECCメカニズムは、ビアーのビアルーターのビットの割り当てと、ビアテの隣接に使用できます。PCECCベースのコントローラーは、PCEPを使用して、ビットの意味とビアカプセル化に必要な他のフィールドについて、ビア対応ルーターに指示することができます。PCECCを使用して、ノードと隣接の両方について、Bierカプセル化（Bier Sub-Domain-ID、BFR-IDなど）で使用されるさまざまなパラメーターを使用してBierルーターをプログラムできます。" + }, + { + "indent": 3, + "text": "A possible way to use the PCECC and PCEP extension is described in [PCECC-BIER].", + "ja": "PCECCおよびPCEP拡張機能を使用する可能性のある方法は、[PCECC-Bier]で説明されています。" + }, + { + "indent": 0, + "text": "4. IANA Considerations", + "section_title": true, + "ja": "4. IANAの考慮事項" + }, + { + "indent": 3, + "text": "This document has no IANA actions.", + "ja": "このドキュメントにはIANAアクションがありません。" + }, + { + "indent": 0, + "text": "5. Security Considerations", + "section_title": true, + "ja": "5. セキュリティに関する考慮事項" + }, + { + "indent": 3, + "text": "[RFC8283] describes how the security considerations for a PCECC are a little different from those for any other PCE system. PCECC operations rely heavily on the use and security of PCEP, so due consideration should be given to the security features discussed in [RFC5440] and the additional mechanisms described in [RFC8253]. It further lists the vulnerability of a central controller architecture, such as a central point of failure, denial of service, and a focus on interception and modification of messages sent to individual Network Elements (NEs).", + "ja": "[RFC8283]は、PCECCのセキュリティ上の考慮事項が他のPCEシステムのセキュリティに関する考慮事項とは少し異なる方法を説明しています。PCECCの操作は、PCEPの使用とセキュリティに大きく依存しているため、[RFC5440]で説明されているセキュリティ機能と[RFC8253]で説明されている追加のメカニズムに十分な考慮を払う必要があります。さらに、障害の中央点、サービス拒否、個々のネットワーク要素（NES）に送信されるメッセージの傍受と変更に焦点を当てるなど、中央コントローラーアーキテクチャの脆弱性をリストします。" + }, + { + "indent": 3, + "text": "As per [RFC9050], the use of Transport Layer Security (TLS) in PCEP is recommended, as it provides support for peer authentication, message encryption, and integrity. It further provides mechanisms for associating peer identities with different levels of access and/ or authoritativeness via an attribute in X.509 certificates or a local policy with a specific accept-list of X.509 certificates. This can be used to check the authority for the PCECC operations.", + "ja": "[RFC9050]によると、PCEPでの輸送層セキュリティ（TLS）の使用が推奨されます。これは、ピア認証、メッセージ暗号化、および完全性をサポートするためです。さらに、X.509証明書の属性またはX.509証明書の特定の受け入れリストを持つ属性を介して、異なるレベルのアクセスおよび/または権威性を持つピアアイデンティティを関連付けるためのメカニズムを提供します。これは、PCECC操作の権限を確認するために使用できます。" + }, + { + "indent": 3, + "text": "It is expected that each new document that is produced for a specific use case will also include considerations of the security impacts of the use of a PCECC on the network type and services being managed.", + "ja": "特定のユースケース用に作成された各新しいドキュメントには、管理対象のネットワークタイプとサービスに対するPCECCの使用のセキュリティへの影響に関する考慮事項も含まれることが期待されています。" + }, + { + "indent": 0, + "text": "6. References", + "section_title": true, + "ja": "6. 参考文献" + }, + { + "indent": 0, + "text": "6.1. Normative References", + "section_title": true, + "ja": "6.1. 引用文献" + }, + { + "indent": 3, + "text": "[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., \"Path Computation\n Element (PCE) Communication Protocol (PCEP)\", RFC 5440,\n DOI 10.17487/RFC5440, March 2009,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., \"Service Function\n Chaining (SFC) Architecture\", RFC 7665,\n DOI 10.17487/RFC7665, October 2015,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, \"Path\n Computation Element Communication Protocol (PCEP)\n Extensions for Stateful PCE\", RFC 8231,\n DOI 10.17487/RFC8231, September 2017,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,\n \"PCEPS: Usage of TLS to Provide a Secure Transport for the\n Path Computation Element Communication Protocol (PCEP)\",\n RFC 8253, DOI 10.17487/RFC8253, October 2017,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, \"Path\n Computation Element Communication Protocol (PCEP)\n Extensions for PCE-Initiated LSP Setup in a Stateful PCE\n Model\", RFC 8281, DOI 10.17487/RFC8281, December 2017,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, \"An\n Architecture for Use of PCE and the PCE Communication\n Protocol (PCEP) in a Network with Central Control\",\n RFC 8283, DOI 10.17487/RFC8283, December 2017,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,\n Decraene, B., Litkowski, S., and R. Shakir, \"Segment\n Routing Architecture\", RFC 8402, DOI 10.17487/RFC8402,\n July 2018, .", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "6.2. Informative References", + "section_title": true, + "ja": "6.2. 参考引用" + }, + { + "indent": 3, + "text": "[MAP-REDUCE]\n Lee, K., Choi, T., Ganguly, A., Wolinsky, D., Boykin, P.,\n and R. Figueiredo, \"Parallel Processing Framework on a P2P\n System Using Map and Reduce Primitives\",\n DOI 10.1109/IPDPS.2011.315, May 2011,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[MPLS-DC] Afanasiev, D. and D. Ginsburg, \"MPLS in DC and inter-DC\n networks: the unified forwarding mechanism for network\n programmability at scale\", March 2014,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[MPLS-SEAMLESS]\n Leymann, N., Ed., Decraene, B., Filsfils, C.,\n Konstantynowicz, M., Ed., and D. Steinberg, \"Seamless MPLS\n Architecture\", Work in Progress, Internet-Draft, draft-\n ietf-mpls-seamless-mpls-07, 28 June 2014,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[PCE-ID] Li, C., Shi, H., Ed., Wang, A., Cheng, W., and C. Zhou,\n \"Path Computation Element Communication Protocol (PCEP)\n extension to advertise the PCE Controlled Identifier\n Space\", Work in Progress, Internet-Draft, draft-ietf-pce-\n controlled-id-space-01, 21 October 2024,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[PCE-INTERDOMAIN]\n Dugeon, O., Meuric, J., Lee, Y., and D. Ceccarelli, \"PCEP\n Extension for Stateful Inter-Domain Tunnels\", Work in\n Progress, Internet-Draft, draft-ietf-pce-stateful-\n interdomain-05, 5 July 2024,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[PCE-PROTECTION]\n Barth, C. and R. Torvi, \"PCEP Extensions for RSVP-TE\n Local-Protection with PCE-Stateful\", Work in Progress,\n Internet-Draft, draft-cbrt-pce-stateful-local-protection-\n 01, 29 June 2018, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[PCECC-BIER]\n Chen, R., Zhu, C., Xu, B., Chen, H., and A. Wang, \"PCEP\n Procedures and Protocol Extensions for Using PCE as a\n Central Controller (PCECC) of BIER\", Work in Progress,\n Internet-Draft, draft-chen-pce-pcep-extension-pce-\n controller-bier-06, 8 July 2024,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[PCECC-SR] Li, Z., Peng, S., Negi, M. S., Zhao, Q., and C. Zhou, \"PCE\n Communication Protocol (PCEP) Extensions for Using PCE as\n a Central Controller (PCECC) for Segment Routing (SR) MPLS\n Segment Identifier (SID) Allocation and Distribution.\",\n Work in Progress, Internet-Draft, draft-ietf-pce-pcep-\n extension-pce-controller-sr-09, 4 July 2024,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[PCECC-SRv6]\n Li, Z., Peng, S., Geng, X., and M. S. Negi, \"PCE\n Communication Protocol (PCEP) Extensions for Using the PCE\n as a Central Controller (PCECC) for Segment Routing over\n IPv6 (SRv6) Segment Identifier (SID) Allocation and\n Distribution.\", Work in Progress, Internet-Draft, draft-\n ietf-pce-pcep-extension-pce-controller-srv6-03, 18 August\n 2024, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[PCEP-BIER]\n Chen, R., Zhang, Z., Chen, H., Dhanaraj, S., Qin, F., and\n A. Wang, \"PCEP Extensions for Tree Engineering for Bit\n Index Explicit Replication (BIER-TE)\", Work in Progress,\n Internet-Draft, draft-ietf-pce-bier-te-01, 10 October\n 2024, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[PCEP-NATIVE]\n Wang, A., Khasanov, B., Fang, S., Tan, R., and C. Zhu,\n \"Path Computation Element Communication Protocol (PCEP)\n Extensions for Native IP Networks\", Work in Progress,\n Internet-Draft, draft-ietf-pce-pcep-extension-native-ip-\n 40, 10 September 2024,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[PCEP-POLICY]\n Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H.\n Bidgoli, \"Path Computation Element Communication Protocol\n (PCEP) Extensions for Segment Routing (SR) Policy\n Candidate Paths\", Work in Progress, Internet-Draft, draft-\n ietf-pce-segment-routing-policy-cp-18, 14 October 2024,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC1195] Callon, R., \"Use of OSI IS-IS for routing in TCP/IP and\n dual environments\", RFC 1195, DOI 10.17487/RFC1195,\n December 1990, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC2328] Moy, J., \"OSPF Version 2\", STD 54, RFC 2328,\n DOI 10.17487/RFC2328, April 1998,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,\n and G. Swallow, \"RSVP-TE: Extensions to RSVP for LSP\n Tunnels\", RFC 3209, DOI 10.17487/RFC3209, December 2001,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC3985] Bryant, S., Ed. and P. Pate, Ed., \"Pseudo Wire Emulation\n Edge-to-Edge (PWE3) Architecture\", RFC 3985,\n DOI 10.17487/RFC3985, March 2005,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC4206] Kompella, K. and Y. Rekhter, \"Label Switched Paths (LSP)\n Hierarchy with Generalized Multi-Protocol Label Switching\n (GMPLS) Traffic Engineering (TE)\", RFC 4206,\n DOI 10.17487/RFC4206, October 2005,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC4364] Rosen, E. and Y. Rekhter, \"BGP/MPLS IP Virtual Private\n Networks (VPNs)\", RFC 4364, DOI 10.17487/RFC4364, February\n 2006, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC4456] Bates, T., Chen, E., and R. Chandra, \"BGP Route\n Reflection: An Alternative to Full Mesh Internal BGP\n (IBGP)\", RFC 4456, DOI 10.17487/RFC4456, April 2006,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, \"A Path\n Computation Element (PCE)-Based Architecture\", RFC 4655,\n DOI 10.17487/RFC4655, August 2006,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,\n \"LDP Specification\", RFC 5036, DOI 10.17487/RFC5036,\n October 2007, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC5150] Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel,\n \"Label Switched Path Stitching with Generalized\n Multiprotocol Label Switching Traffic Engineering (GMPLS\n TE)\", RFC 5150, DOI 10.17487/RFC5150, February 2008,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC5151] Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, \"Inter-\n Domain MPLS and GMPLS Traffic Engineering -- Resource\n Reservation Protocol-Traffic Engineering (RSVP-TE)\n Extensions\", RFC 5151, DOI 10.17487/RFC5151, February\n 2008, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, \"OSPF\n for IPv6\", RFC 5340, DOI 10.17487/RFC5340, July 2008,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC5376] Bitar, N., Zhang, R., and K. Kumaki, \"Inter-AS\n Requirements for the Path Computation Element\n Communication Protocol (PCECP)\", RFC 5376,\n DOI 10.17487/RFC5376, November 2008,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, \"Encoding of\n Objective Functions in the Path Computation Element\n Communication Protocol (PCEP)\", RFC 5541,\n DOI 10.17487/RFC5541, June 2009,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C.\n Margaria, \"Requirements for GMPLS Applications of PCE\",\n RFC 7025, DOI 10.17487/RFC7025, September 2013,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC7399] Farrel, A. and D. King, \"Unanswered Questions in the Path\n Computation Element Architecture\", RFC 7399,\n DOI 10.17487/RFC7399, October 2014,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,\n Uttaro, J., Drake, J., and W. Henderickx, \"BGP MPLS-Based\n Ethernet VPN\", RFC 7432, DOI 10.17487/RFC7432, February\n 2015, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC7491] King, D. and A. Farrel, \"A PCE-Based Architecture for\n Application-Based Network Operations\", RFC 7491,\n DOI 10.17487/RFC7491, March 2015,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,\n Przygienda, T., and S. Aldrin, \"Multicast Using Bit Index\n Explicit Replication (BIER)\", RFC 8279,\n DOI 10.17487/RFC8279, November 2017,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,\n \"Network Service Header (NSH)\", RFC 8300,\n DOI 10.17487/RFC8300, January 2018,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8355] Filsfils, C., Ed., Previdi, S., Ed., Decraene, B., and R.\n Shakir, \"Resiliency Use Cases in Source Packet Routing in\n Networking (SPRING) Networks\", RFC 8355,\n DOI 10.17487/RFC8355, March 2018,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J.\n Hardwick, \"Conveying Path Setup Type in PCE Communication\n Protocol (PCEP) Messages\", RFC 8408, DOI 10.17487/RFC8408,\n July 2018, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,\n and J. Hardwick, \"Path Computation Element Communication\n Protocol (PCEP) Extensions for Segment Routing\", RFC 8664,\n DOI 10.17487/RFC8664, December 2019,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8735] Wang, A., Huang, X., Kou, C., Li, Z., and P. Mi,\n \"Scenarios and Simulation Results of PCE in a Native IP\n Network\", RFC 8735, DOI 10.17487/RFC8735, February 2020,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8751] Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., and D. King,\n \"Hierarchical Stateful Path Computation Element (PCE)\",\n RFC 8751, DOI 10.17487/RFC8751, March 2020,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,\n Matsushima, S., and D. Voyer, \"IPv6 Segment Routing Header\n (SRH)\", RFC 8754, DOI 10.17487/RFC8754, March 2020,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8821] Wang, A., Khasanov, B., Zhao, Q., and H. Chen, \"PCE-Based\n Traffic Engineering (TE) in Native IP Networks\", RFC 8821,\n DOI 10.17487/RFC8821, April 2021,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8955] Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M.\n Bacher, \"Dissemination of Flow Specification Rules\",\n RFC 8955, DOI 10.17487/RFC8955, December 2020,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,\n D., Matsushima, S., and Z. Li, \"Segment Routing over IPv6\n (SRv6) Network Programming\", RFC 8986,\n DOI 10.17487/RFC8986, February 2021,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,\n \"The BGP Tunnel Encapsulation Attribute\", RFC 9012,\n DOI 10.17487/RFC9012, April 2021,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC9050] Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, \"Path\n Computation Element Communication Protocol (PCEP)\n Procedures and Extensions for Using the PCE as a Central\n Controller (PCECC) of LSPs\", RFC 9050,\n DOI 10.17487/RFC9050, July 2021,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC9087] Filsfils, C., Ed., Previdi, S., Dawra, G., Ed., Aries, E.,\n and D. Afanasiev, \"Segment Routing Centralized BGP Egress\n Peer Engineering\", RFC 9087, DOI 10.17487/RFC9087, August\n 2021, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC9168] Dhody, D., Farrel, A., and Z. Li, \"Path Computation\n Element Communication Protocol (PCEP) Extension for Flow\n Specification\", RFC 9168, DOI 10.17487/RFC9168, January\n 2022, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,\n A., and P. Mattes, \"Segment Routing Policy Architecture\",\n RFC 9256, DOI 10.17487/RFC9256, July 2022,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC9262] Eckert, T., Ed., Menth, M., and G. Cauchie, \"Tree\n Engineering for Bit Index Explicit Replication (BIER-TE)\",\n RFC 9262, DOI 10.17487/RFC9262, October 2022,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC9491] Guichard, J., Ed. and J. Tantsura, Ed., \"Integration of\n the Network Service Header (NSH) and Segment Routing for\n Service Function Chaining (SFC)\", RFC 9491,\n DOI 10.17487/RFC9491, November 2023,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC9522] Farrel, A., Ed., \"Overview and Principles of Internet\n Traffic Engineering\", RFC 9522, DOI 10.17487/RFC9522,\n January 2024, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC9552] Talaulikar, K., Ed., \"Distribution of Link-State and\n Traffic Engineering Information Using BGP\", RFC 9552,\n DOI 10.17487/RFC9552, December 2023,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC9603] Li, C., Ed., Kaladharan, P., Sivabalan, S., Koldychev, M.,\n and Y. Zhu, \"Path Computation Element Communication\n Protocol (PCEP) Extensions for IPv6 Segment Routing\",\n RFC 9603, DOI 10.17487/RFC9603, July 2024,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC9604] Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S.,\n and C. Li, Ed., \"Carrying Binding Label/SID in PCE-Based\n Networks\", RFC 9604, DOI 10.17487/RFC9604, August 2024,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[SR-SERVICE]\n Clad, F., Ed., Xu, X., Ed., Filsfils, C., Bernier, D., Li,\n C., Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W.,\n and S. Salsano, \"Service Programming with Segment\n Routing\", Work in Progress, Internet-Draft, draft-ietf-\n spring-sr-service-programming-10, 23 August 2024,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "Appendix A. Other Use Cases of the PCECC", + "section_title": true, + "ja": "付録A. PCECCのその他のユースケース" + }, + { + "indent": 3, + "text": "This section lists some more use cases of the PCECC that were proposed by operators and discussed within the working group but are not in active development at the time of publication. They are listed here for future consideration.", + "ja": "このセクションでは、オペレーターによって提案され、ワーキンググループ内で議論されたが、出版時には積極的な開発にはないPCECCのいくつかの使用ケースをリストします。将来の検討のためにここにリストされています。" + }, + { + "indent": 0, + "text": "A.1. PCECC for Network Migration", + "section_title": true, + "ja": "A.1. ネットワーク移行のためのPCECC" + }, + { + "indent": 3, + "text": "One of the main advantages of the PCECC solution is its backward compatibility. The PCE server can function as a proxy node of the MPLS network for all the new nodes that no longer support the signalling protocols.", + "ja": "PCECCソリューションの主な利点の1つは、後方互換性です。PCEサーバーは、シグナリングプロトコルをサポートしなくなったすべての新しいノードのMPLSネットワークのプロキシノードとして機能することができます。" + }, + { + "indent": 3, + "text": "As illustrated in the following example, the current network could migrate to a total PCECC-controlled network gradually by replacing the legacy nodes. During the migration, the legacy nodes still need to use the existing MPLS signalling protocols such as LDP and RSVP-TE, and the new nodes will set up their portion of the forwarding path through the PCECC directly. With the PCECC function as the proxy of these new nodes, MPLS signalling can populate through the network for both old and new nodes.", + "ja": "次の例に示されているように、現在のネットワークは、レガシーノードを置き換えることにより、PCECC制御ネットワーク全体に徐々に移行する可能性があります。移行中、レガシーノードは依然としてLDPやRSVP-TEなどの既存のMPLSシグナリングプロトコルを使用する必要があり、新しいノードはPCECCを介して転送パスの部分を直接設定します。これらの新しいノードのプロキシとしてPCECC機能を使用すると、MPLSシグナル伝達は、古いノードと新しいノードの両方でネットワークを介して入力できます。" + }, + { + "indent": 3, + "text": "The example described in this section is based on network configurations illustrated in Figure 13:", + "ja": "このセクションで説明する例は、図13に示すネットワーク構成に基づいています。" + }, + { + "indent": 3, + "text": "+------------------------------------------------------------------+\n| PCE DOMAIN |\n| +-----------------------------------------------------+ |\n| | PCECC | |\n| +-----------------------------------------------------+ |\n| ^ ^ ^ ^ |\n| | PCEP | | PCEP | |\n| V V V V |\n| +--------+ +--------+ +--------+ +--------+ +--------+ |\n| | Node1 | | Node2 | | Node3 | | Node4 | | Node5 | |\n| | |...| |...| |...| |...| | |\n| | Legacy |if1| Legacy |if2|Legacy |if3| PCECC |if4| PCECC | |\n| | Node | | Node | |Enabled | |Enabled | | Enabled| |\n| +--------+ +--------+ +--------+ +--------+ +--------+ |\n| |\n+------------------------------------------------------------------+", + "raw": true, + "ja": "" + }, + { + "indent": 7, + "text": "Figure 13: PCECC-Initiated LSP Setup in the Network Migration", + "ja": "図13：ネットワーク移行におけるPCECCによって開始されたLSPセットアップ" + }, + { + "indent": 3, + "text": "In this example, there are five nodes for the TE LSP from the headend (Node1) to the tail end (Node5), where Node4 and Node5 are centrally controlled and other nodes are legacy nodes.", + "ja": "この例では、ヘッドエンド（node1）からテールエンド（node5）までのte lspの5つのノードがあり、node4とnode5は中心に制御され、他のノードはレガシーノードです。" + }, + { + "indent": 6, + "text": "* Node1 sends a path request message for the setup of the LSP with the destination as Node5.", + "ja": "* node1は、LSPのセットアップのパス要求メッセージをNode5として宛先とともに送信します。" + }, + { + "indent": 6, + "text": "* The PCECC sends a reply message to Node1 for LSP setup with the path: (Node1, if1), (Node2, if2), (Node3, if3), (Node4, if4), Node5.", + "ja": "* PCECCは、パス：（node1、if1）、（node2、if2）、（node3、if3）、（node4、if4）、node5を使用して、lspセットアップに対してnode1に返信メッセージを送信します。" + }, + { + "indent": 6, + "text": "* Node1, Node2, and Node3 will set up the LSP to Node5 using the local labels as usual. With the help of the PCECC, Node3 could proxy the signalling.", + "ja": "* node1、node2、およびnode3は、通常どおりローカルラベルを使用してLSPをnode5に設定します。PCECCの助けを借りて、node3はシグナリングをプロキシできます。" + }, + { + "indent": 6, + "text": "* Then, the PCECC will program the out-segment of Node3, the in-segment/out-segment of Node4, and the in-segment for Node5.", + "ja": "* 次に、PCECCは、node3のアウトセグメント、node4のインセグメント/アウトセグメント、およびnode5のセグメントをプログラムします。" + }, + { + "indent": 0, + "text": "A.2. PCECC for L3VPN and PWE3", + "section_title": true, + "ja": "A.2. L3VPNおよびPWE3のPCECC" + }, + { + "indent": 3, + "text": "As described in [RFC8283], various network services may be offered over a network. These include protection services (including Virtual Private Network (VPN) services such as L3VPN [RFC4364] or EVPNs [RFC7432]) or pseudowires [RFC3985]. Delivering services over a network in an optimal way requires coordination in the way where network resources are allocated to support the services. A PCECC can consider the whole network and all components of a service at once when planning how to deliver the service. It can then use PCEP to manage the network resources and to install the necessary associations between those resources.", + "ja": "[RFC8283]で説明されているように、さまざまなネットワークサービスがネットワークを介して提供される場合があります。これらには、保護サービス（L3VPN [RFC4364]やEVPNS [RFC7432]などの仮想プライベートネットワーク（VPN）サービスを含む）またはプソイドワイヤ[RFC3985]が含まれます。ネットワーク上でサービスを最適な方法で提供するには、サービスをサポートするためにネットワークリソースが割り当てられる方法で調整が必要です。PCECCは、サービスの提供方法を計画する際に、ネットワーク全体とサービスのすべてのコンポーネントを一度に考慮することができます。その後、PCEPを使用してネットワークリソースを管理し、それらのリソース間に必要な関連付けをインストールできます。" + }, + { + "indent": 3, + "text": "In the case of L3VPN, VPN labels could also be assigned and distributed through PCEP among the Provider Edge (PE) router instead of using the BGP protocols.", + "ja": "L3VPNの場合、VPNラベルは、BGPプロトコルを使用する代わりに、プロバイダーエッジ（PE）ルーターの間でPCEPを介して割り当てて分布することもできます。" + }, + { + "indent": 3, + "text": "The example described in this section is based on network configurations illustrated in Figure 14:", + "ja": "このセクションで説明する例は、図14に示すネットワーク構成に基づいています。" + }, + { + "indent": 4, + "text": " +-------------------------------------------+\n | PCE DOMAIN |\n | +-----------------------------------+ |\n | | PCECC | |\n | +-----------------------------------+ |\n | ^ ^ ^ |\n | PWE3/L3VPN|PCEP PCEP|LSP PWE3/L3VPN|PCEP |\n | V V V |\n+--------+ | +--------+ +--------+ +--------+ | +--------+\n| CE | | | PE1 | | Node x | | PE2 | | | CE |\n| |...... | |...| |...| |.....| |\n| Legacy | |if1 | PCECC |if2|PCECC |if3| PCECC |if4 | Legacy |\n| Node | | | Enabled| |Enabled | |Enabled | | | Node |\n+--------+ | +--------+ +--------+ +--------+ | +--------+\n | |\n +-------------------------------------------+", + "raw": true, + "ja": "" + }, + { + "indent": 20, + "text": "Figure 14: PCECC for L3VPN and PWE3", + "ja": "図14：L3VPNおよびPWE3のPCECC" + }, + { + "indent": 3, + "text": "In the case of PWE3, instead of using the LDP signalling protocols, the label and port pairs assigned to each pseudowire can be assigned through the PCECC among the PE routers and the corresponding forwarding entries will be distributed into each PE router through the extended PCEP and PCECC mechanism.", + "ja": "PWE3の場合、LDPシグナル伝達プロトコルを使用する代わりに、各擬似ワイヤに割り当てられたラベルとポートペアは、PEルーターの間でPCECCを介して割り当てることができ、対応する転送エントリは拡張されたPCEPを介して各PEルーターに配布されます。PCECCメカニズム。" + }, + { + "indent": 0, + "text": "A.3. PCECC for Local Protection (RSVP-TE)", + "section_title": true, + "ja": "A.3. ローカル保護のためのPCECC（RSVP-TE）" + }, + { + "indent": 3, + "text": "[PCE-PROTECTION] claims that there is a need for the PCE to maintain and associate the local protection paths for the RSVP-TE LSP. Local protection requires the setup of a bypass at the PLR. This bypass can be PCC-initiated and delegated or PCE-initiated. In either case, the PLR needs to maintain a PCEP session with the PCE. The bypass LSPs need to be mapped to the primary LSP. This could be done locally at the PLR based on a local policy, but there is a need for a PCE to do the mapping as well to exert greater control.", + "ja": "[PCE保護]は、PCEがRSVP-TE LSPのローカル保護パスを維持および関連付ける必要があると主張しています。ローカル保護には、PLRでのバイパスのセットアップが必要です。このバイパスは、PCC開始および委任またはPCE開始を行うことができます。どちらの場合でも、PLRはPCEとのPCEPセッションを維持する必要があります。バイパスLSPをプライマリLSPにマッピングする必要があります。これは、ローカルポリシーに基づいてPLRでローカルに行うことができますが、PCEがマッピングを行う必要があります。" + }, + { + "indent": 3, + "text": "This mapping can be done via PCECC procedures where the PCE could instruct the PLR to the mapping and identify the primary LSP for which bypass should be used.", + "ja": "このマッピングは、PCEがPLRにマッピングを指示し、バイパスを使用する主要なLSPを識別できるPCECC手順を介して実行できます。" + }, + { + "indent": 0, + "text": "A.4. Using Reliable P2MP TE-Based Multicast Delivery for Distributed Computations (MapReduce-Hadoop)", + "section_title": true, + "ja": "A.4. 分散計算に信頼性の高いP2MP TEベースのマルチキャスト配信を使用（MapReduce-Hadoop）" + }, + { + "indent": 3, + "text": "The MapReduce model of distributed computations in computing clusters is widely deployed. In Hadoop (https://hadoop.apache.org/) 1.0 architecture, MapReduce operations occur on big data in the Hadoop Distributed File System (HDFS), where NameNode knows about resources of the cluster and where actual data (chunks) for a particular task are located (which DataNode). Each chunk of data (64 MB or more) should have three saved copies in different DataNodes based on their proximity.", + "ja": "コンピューティングクラスターの分散計算のMapReduceモデルは広く展開されています。Hadoop（https://hadoop.apache.org/）1.0アーキテクチャでは、MapReduce操作はHadoop分散ファイルシステム（HDFS）のビッグデータで発生します。特定のタスクが配置されています（このデータノード）。データの各チャンク（64 MB以上）には、近接に基づいて異なるデータノードに3つの保存されたコピーが必要です。" + }, + { + "indent": 3, + "text": "The proximity level currently has a semi-manual allocation and is based on Rack IDs (the assumption is that closer data is better because of access speed / smaller latency).", + "ja": "近接レベルには現在、セミマニュアル割り当てがあり、ラックIDに基づいています（アクセス速度 /レイテンシーが小さいため、より近いデータが優れていると仮定しています）。" + }, + { + "indent": 3, + "text": "The JobTracker node is responsible for computation tasks and scheduling across DataNodes and also has Rack awareness. Currently, transport protocols between NameNode/JobTracker and DataNodes are based on IP unicast. It has simplicity as an advantage but has numerous drawbacks related to its flat approach.", + "ja": "JobTrackerノードは、DataNodes全体の計算タスクとスケジューリングを担当し、ラック認識もあります。現在、NameNode/JobTrackerとDatanodesの間の輸送プロトコルは、IPユニキャストに基づいています。それは利点としてシンプルさを持っていますが、そのフラットなアプローチに関連する多くの欠点があります。" + }, + { + "indent": 3, + "text": "There is a need to go beyond one data center (DC) for Hadoop cluster creation and move towards distributed clusters. In that case, one needs to handle performance and latency issues. Latency depends on the speed of light in the fiber links and on the latency introduced by intermediate devices in between. The latter is closely correlated with network device architecture and performance. The current performance of routers based on Network Processing Unit (NPU) should be enough for creating distributed Hadoop clusters with predicted latency. The performance of software-based routers (mainly Virtual Network Functions (VNFs)) with additional hardware features such as the Data Plane Development Kit (DPDK) is promising but requires additional research and testing.", + "ja": "Hadoopクラスターの作成には、1つのデータセンター（DC）を超えて、分散クラスターに向かって移動する必要があります。その場合、パフォーマンスとレイテンシの問題を処理する必要があります。遅延は、ファイバーリンクの光の速度と、その間の中間デバイスによって導入されたレイテンシに依存します。後者は、ネットワークデバイスのアーキテクチャとパフォーマンスと密接に相関しています。ネットワーク処理ユニット（NPU）に基づくルーターの現在のパフォーマンスは、予測された遅延を備えた分散Hadoopクラスターを作成するのに十分でなければなりません。データプレーン開発キット（DPDK）などの追加のハードウェア機能を備えたソフトウェアベースのルーター（主に仮想ネットワーク関数（VNFS））のパフォーマンスは有望ですが、追加の研究とテストが必要です。" + }, + { + "indent": 3, + "text": "The main question is how to create a simple but effective architecture for a distributed Hadoop cluster.", + "ja": "主な問題は、分散型Hadoopクラスターのシンプルだが効果的なアーキテクチャをどのように作成するかです。" + }, + { + "indent": 3, + "text": "There is research [MAP-REDUCE] that shows how usage of the multicast tree could improve the speed of resource or cluster members' discovery inside the cluster as well as increased redundancy in communications between cluster nodes.", + "ja": "マルチキャストツリーの使用がクラスター内のリソースまたはクラスターメンバーの発見の速度をどのように改善し、クラスターノード間の通信の冗長性を高めることができるかを示す研究[Map-Reduce]があります。" + }, + { + "indent": 3, + "text": "The conventional IP-based multicast may not be appropriate because it requires an additional control plane (IGMP, PIM) and a lot of signalling, which is not suitable for high-performance computations that are very sensitive to latency.", + "ja": "従来のIPベースのマルチキャストは、追加のコントロールプレーン（IGMP、PIM）と多くのシグナル伝達が必要であるため、適切ではない場合があります。" + }, + { + "indent": 3, + "text": "P2MP TE tunnels are more suitable as a potential solution for the creation of multicast-based communications between NameNode as the root and DataNodes as leaves inside the cluster. These P2MP tunnels could be dynamically created and turned down (with no manual intervention). Here, the PCECC comes into play with the main objective of creating an optimal topology for each particular request for MapReduce computation and creating P2MP tunnels with needed parameters such as BW and delay.", + "ja": "P2MP TEトンネルは、クラスター内の葉としてのルートとしてのナメノーデとデータノードの間のマルチキャストベースの通信を作成するための潜在的なソリューションとしてより適しています。これらのP2MPトンネルは、動的に作成されて倒すことができます（手動介入なし）。ここで、PCECCは、MapReduce計算の特定の要求に対して最適なトポロジを作成し、BWや遅延などの必要なパラメーターを備えたP2MPトンネルを作成するという主な目的で作用します。" + }, + { + "indent": 3, + "text": "This solution will require the use of MPLS label-based forwarding inside the cluster. The usage of label-based forwarding inside DC was proposed by Yandex [MPLS-DC]. Technically, it is already possible because MPLS on switches is already supported by some vendors, and MPLS also exists on Linux and Open vSwitch (OVS).", + "ja": "このソリューションでは、クラスター内のMPLSラベルベースの転送を使用する必要があります。DC内のラベルベースの転送の使用は、Yandex [MPLS-DC]によって提案されました。技術的には、スイッチ上のMPLSは一部のベンダーによってすでにサポートされており、MPLSはLinuxおよびOpen Vswitch（OVS）にも存在するため、すでに可能です。" + }, + { + "indent": 3, + "text": "A possible framework for this task is shown in Figure 15:", + "ja": "このタスクの可能なフレームワークを図15に示します。" + }, + { + "indent": 3, + "text": " +--------+\n | APP |\n +--------+\n | NBI (REST API,...)\n |\n PCEP +----------+ REST API\n +---------+ +---| PCECC |----------+\n | Client |---|---| | |\n +---------+ | +----------+ |\n | | | | | |\n +-----|---+ |PCEP| |\n +--------+ | | | | |\n | | | | | |\n | REST API | | | | |\n | | | | | |\n+-------------+ | | | | +----------+\n| Job Tracker | | | | | | NameNode |\n| | | | | | | |\n+-------------+ | | | | +----------+\n +------------------+ | +-----------+\n | | | |\n |---+-----P2MP TE--+-----|-----------| |\n+-----------+ +-----------+ +-----------+\n| DataNode1 | | DataNode2 | | DataNodeN |\n|TaskTracker| |TaskTracker| .... |TaskTracker|\n+-----------+ +-----------+ +-----------+", + "raw": true, + "ja": "" + }, + { + "indent": 7, + "text": "Figure 15: Using Reliable P2MP TE-Based Multicast Delivery for Distributed Computations (MapReduce-Hadoop)", + "ja": "図15：分散計算に信頼できるP2MP TEベースのマルチキャスト配信の使用（MapReduce-Hadoop）" + }, + { + "indent": 3, + "text": "Communication between the JobTracker, NameNode, and PCECC can be done via REST API directly or via a cluster manager such as Mesos.", + "ja": "JobTracker、Namenode、およびPCECC間の通信は、REST APIを直接またはMESOなどのクラスターマネージャーを介して実行できます。" + }, + { + "indent": 6, + "text": "* Phase 1: Distributed cluster resource discovery occurs during this phase. JobTracker and NameNode should identify and find available DataNodes according to computing requests from the application (APP). NameNode should query the PCECC about available DataNodes, and NameNode may provide additional constraints to the PCECC such as topological proximity and redundancy level.", + "ja": "* フェーズ1：分散クラスターリソースの発見は、このフェーズで発生します。JobTrackerとNameNodeは、アプリケーション（APP）からのコンピューティング要求に従って、利用可能なデータノードを識別して見つけて見つける必要があります。NameNodeは、利用可能なデータノードについてPCECCを照会する必要があり、NameNodeはトポロジーの近接性や冗長性レベルなどのPCECCに追加の制約を提供する場合があります。" + }, + { + "indent": 10, + "text": "The PCECC should analyze the topology of the distributed cluster and perform a constraint-based path calculation from the client towards the most suitable NameNodes. The PCECC should reply to NameNode with the list of the most suitable DataNodes and their resource capabilities. The topology discovery mechanism for the PCECC will be added later to that framework.", + "ja": "PCECCは、分散クラスターのトポロジを分析し、クライアントから最も適切なナメノードへの制約ベースのパス計算を実行する必要があります。PCECCは、最も適切なデータノードとそのリソース機能のリストを使用してNamenodeに返信する必要があります。PCECCのトポロジ発見メカニズムは、後でそのフレームワークに追加されます。" + }, + { + "indent": 6, + "text": "* Phase 2: The PCECC should create P2MP LSPs from the client towards those DataNodes by means of PCEP messages following the previously calculated path.", + "ja": "* フェーズ2：PCECCは、以前に計算されたパスに続いてPCEPメッセージを使用して、クライアントからそれらのデータロードに向かってP2MP LSPを作成する必要があります。" + }, + { + "indent": 6, + "text": "* Phase 3: NameNode should send this information to the client, and the PCECC should inform the client about the optimal P2MP path towards DataNodes via a PCEP message.", + "ja": "* フェーズ3：NAMENODEはこの情報をクライアントに送信する必要があり、PCECCはPCEPメッセージを介してDatanodesへの最適なP2MPパスについてクライアントに通知する必要があります。" + }, + { + "indent": 6, + "text": "* Phase 4: The client sends data blocks to those DataNodes for writing via the created P2MP tunnel.", + "ja": "* フェーズ4：クライアントは、作成されたP2MPトンネルを介して書き込むために、これらのデータロードにデータブロックを送信します。" + }, + { + "indent": 3, + "text": "When this task is finished, the P2MP tunnel could be turned down.", + "ja": "このタスクが終了すると、P2MPトンネルを倒すことができます。" + }, + { + "indent": 0, + "text": "Acknowledgments", + "section_title": true, + "ja": "謝辞" + }, + { + "indent": 3, + "text": "Thanks to Adrian Farrel, Aijun Wang, Robert Tao, Changjiang Yan, Tieying Huang, Sergio Belotti, Dieter Beller, Andrey Elperin, and Evgeniy Brodskiy for their useful comments and suggestions.", + "ja": "エイドリアン・ファレル、アイジュン・ワン、ロバート・タオ、チャンジャン・ヤン、ティーイング・ファン、セルジオ・ベロッティ、ディーター・ベラー、アンドレイ・エルペリン、エヴゲニー・ブロズキーの有用なコメントと提案のおかげで。" + }, + { + "indent": 3, + "text": "Thanks to Mach Chen and Carlos Pignataro for the RTGDIR review. Thanks to Derrell Piper for the SECDIR review. Thanks to Sue Hares for GENART review.", + "ja": "RTGDIRレビューをしてくれたMach ChenとCarlos Pignataroに感謝します。SecdirレビューをしてくれたDerrell Piperに感謝します。GenArt ReviewのSue Haresに感謝します。" + }, + { + "indent": 3, + "text": "Thanks to Vishnu Pavan Beeram for being the document shepherd and Jim Guichard for being the responsible AD.", + "ja": "Vishnu Pavan Bearamが羊飼いであることを担当してくれたJim Guichardに感謝します。" + }, + { + "indent": 3, + "text": "Thanks to Roman Danyliw for the IESG review comments.", + "ja": "IESGレビューのコメントをしてくれたRoman Danyliwに感謝します。" + }, + { + "indent": 0, + "text": "Contributors", + "section_title": true, + "ja": "貢献者" + }, + { + "indent": 3, + "text": "Luyuan Fang\nUnited States of America\nEmail: luyuanf@gmail.com", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Chao Zhou\nHPE\nEmail: chaozhou_us@yahoo.com", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Boris Zhang\nAmazon\nEmail: zhangyud@amazon.com", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Artsiom Rachytski\nAWS\nGermany\nEmail: arachyts@gmail.com", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Anton Hulida\nAWS\nAustralia\nEmail: hulidant@amazon.com", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "Authors' Addresses", + "section_title": true, + "ja": "著者のアドレス" + }, + { + "indent": 3, + "text": "Zhenbin (Robin) Li\nHuawei Technologies\nHuawei Bld., No.156 Beiqing Rd.\nBeijing\n100095\nChina\nEmail: lizhenbin@huawei.com", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Dhruv Dhody\nHuawei Technologies\nIndia\nEmail: dhruv.ietf@gmail.com", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Quintin Zhao\nEtheric Networks\n1009 S Claremont St.\nSan Mateo, CA 94402\nUnited States of America\nEmail: quintinzhao@gmail.com", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "King He\nTencent Holdings Ltd.\nShenzhen\nChina\nEmail: kinghe@tencent.com", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Boris Khasanov\nMTS Web Services (MWS)\nAndropova Ave. 18, building 9\nMoscow\nRussian Federation\nEmail: bhassanov@yahoo.com", + "raw": true, + "ja": "" + } + ] +} \ No newline at end of file diff --git a/data/9000/rfc9697-trans.json b/data/9000/rfc9697-trans.json new file mode 100644 index 000000000..ea1c9b111 --- /dev/null +++ b/data/9000/rfc9697-trans.json @@ -0,0 +1,360 @@ +{ + "title": { + "text": "RFC 9697 - Detecting RPKI Repository Delta Protocol (RRDP) Session Desynchronization", + "ja": "RFC 9697 - RPKIリポジトリデルタプロトコル（RRDP）セッションの解体の検出" + }, + "number": 9697, + "created_at": "2024-12-14 23:24:06.371033+09:00", + "updated_by": "", + "contents": [ + { + "indent": 0, + "text": "Internet Engineering Task Force (IETF) J. Snijders\nRequest for Comments: 9697 Fastly\nUpdates: 8182 T. de Kock\nCategory: Standards Track RIPE NCC\nISSN: 2070-1721 December 2024", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "Detecting RPKI Repository Delta Protocol (RRDP) Session Desynchronization", + "section_title": true, + "ja": "RPKIリポジトリデルタプロトコル（RRDP）セッションの解体の検出" + }, + { + "indent": 0, + "text": "Abstract", + "section_title": true, + "ja": "概要" + }, + { + "indent": 3, + "text": "This document describes an approach for Resource Public Key Infrastructure (RPKI) Relying Parties to detect a particular form of RPKI Repository Delta Protocol (RRDP) session desynchronization and how to recover. This document updates RFC 8182.", + "ja": "このドキュメントでは、RPKIリポジトリデルタプロトコル（RRDP）セッションの非同期化と回復方法を検出するために、リソース公開キーインフラストラクチャ（RPKI）に依存するアプローチについて説明します。このドキュメントは、RFC 8182を更新します。" + }, + { + "indent": 0, + "text": "Status of This Memo", + "section_title": true, + "ja": "本文書の位置付け" + }, + { + "indent": 3, + "text": "This is an Internet Standards Track document.", + "ja": "これは、インターネット標準トラックドキュメントです。" + }, + { + "indent": 3, + "text": "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.", + "ja": "このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。" + }, + { + "indent": 3, + "text": "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/rfc9697.", + "ja": "このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9697で取得できます。" + }, + { + "indent": 0, + "text": "Copyright Notice", + "section_title": true, + "ja": "著作権表示" + }, + { + "indent": 3, + "text": "Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.", + "ja": "著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。" + }, + { + "indent": 3, + "text": "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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.", + "ja": "このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。" + }, + { + "indent": 0, + "text": "Table of Contents", + "section_title": true, + "ja": "目次" + }, + { + "indent": 3, + "text": "1. Introduction\n 1.1. Requirements Language\n2. Immutability of RRDP Files\n3. Detection of Desynchronization\n 3.1. Example\n4. Recovery After Desynchronization\n5. Changes to RFC 8182\n6. Security Considerations\n7. IANA Considerations\n8. References\n 8.1. Normative References\n 8.2. Informative References\nAcknowledgements\nAuthors' Addresses", + "raw": true, + "toc": true, + "ja": "" + }, + { + "indent": 0, + "text": "1. Introduction", + "section_title": true, + "ja": "1. はじめに" + }, + { + "indent": 3, + "text": "The Resource Public Key Infrastructure (RPKI) Repository Delta Protocol (RRDP) [RFC8182] is a one-way synchronization protocol for distributing RPKI data in the form of _differences_ (deltas) between sequential repository states. Relying Parties (RPs) apply a contiguous chain of deltas to synchronize their local copy of the repository with the current state of the remote Repository Server. Delta files for any given session_id and serial number are expected to contain an immutable record of the state of the Repository Server at that given point in time, but this is not always the case.", + "ja": "リソース公開キーインフラストラクチャ（RPKI）リポジトリDelta Protocol（RRDP）[RFC8182]は、_Differences_（Deltas）の形でRPKIデータを配布するための一元配置同期プロトコルです。依存関係者（RPS）は、デルタの連続したチェーンを適用して、リモートリポジトリサーバーの現在の状態とリポジトリのローカルコピーを同期させます。任意のSESSION_IDおよびシリアル番号のDeltaファイルには、その時点でリポジトリサーバーの状態の不変の記録が含まれることが期待されていますが、これは必ずしもそうではありません。" + }, + { + "indent": 3, + "text": "This document describes an approach for RPs to detect a form of RRDP session desynchronization where the hash of a delta for a given serial number and session_id have mutated from the previous Update Notification File and how to recover.", + "ja": "このドキュメントでは、RPSが特定のシリアル番号のデルタのハッシュが以前の更新通知ファイルから変異し、回復する方法から変異したRRDPセッションの解体の形式を検出するためのアプローチについて説明します。" + }, + { + "indent": 0, + "text": "1.1. Requirements Language", + "section_title": true, + "ja": "1.1. 要件言語" + }, + { + "indent": 3, + "text": "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.", + "ja": "「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 \"not\"、 \"becommended\"、 \"becommented\"、 \"may\"、 \"optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。" + }, + { + "indent": 0, + "text": "2. Immutability of RRDP Files", + "section_title": true, + "ja": "2. RRDPファイルの不変性" + }, + { + "indent": 3, + "text": "Section 3.1 of [RFC8182] describes how discrete publication events such as the addition, modification, or deletion of one or more repository objects _can_ be communicated as immutable files, highlighting advantages for publishers, such as the ability to precalculate files and make use of caching infrastructure.", + "ja": "[RFC8182]のセクション3.1は、1つまたは複数のリポジトリオブジェクトの追加、変更、または削除などの個別の出版イベントを、不変のファイルとして伝達する方法を説明し、ファイルを事前に作成し、キャッシュを使用する能力など、出版社の利点を強調しています。インフラストラクチャー。" + }, + { + "indent": 3, + "text": "Even though the global RPKI is understood to present a loosely consistent view that depends on the cache's timing of updates (see Section 6 of [RFC7115]), different caches having different data for the same RRDP session at the same serial violates the principle of least astonishment.", + "ja": "グローバルRPKIは、キャッシュの更新のタイミングに依存するゆるく一貫したビューを提示すると理解されていますが（[RFC7115]、セクション6を参照）、同じシリアルで同じRRDPセッションの異なるデータを持つ異なるキャッシュは、最低の原則に違反します。驚き。" + }, + { + "indent": 3, + "text": "If an RRDP server over time serves differing data for a given session_id and serial number, distinct RP instances (depending on the moment they connected to the RRDP server) would end up with divergent local repositories. Comparing only the server-provided session_id and latest serial number across distinct RP instances would not bring such divergence to light.", + "ja": "RRDPサーバーが時間の経過とともに、特定のsession_idとシリアル番号の異なるデータを提供する場合、個別のRPインスタンス（RRDPサーバーに接続されている瞬間に応じて）は、異なるローカルリポジトリになります。サーバーが提供するSESSION_IDと個別のRPインスタンス間で最新のシリアル番号のみを比較すると、そのような発散が光になりません。" + }, + { + "indent": 3, + "text": "The RRDP specification [RFC8182] alludes to immutability being a property of RRDP files, but it doesn't make it clear that immutability is an absolute requirement for the RRDP to work well.", + "ja": "RRDP仕様[RFC8182]は、RRDPファイルのプロパティであるという不変性を暗示していますが、RRDPがうまく機能するための絶対的な要件であることは明確ではありません。" + }, + { + "indent": 0, + "text": "3. Detection of Desynchronization", + "section_title": true, + "ja": "3. 非同期の検出" + }, + { + "indent": 3, + "text": "Relying Parties can implement a mechanism to keep a record of the serial and hash attribute values in delta elements of the previous successful fetch of an Update Notification File. Then, after fetching a new Update Notification File, the Relying Party should compare if the serial and hash values of previously seen serials match those in the newly fetched file. If any differences are detected, this means that the Delta files were unexpectedly mutated, and the RP should proceed to Section 4.", + "ja": "頼る当事者は、更新通知ファイルの以前の成功したフェッチのデルタ要素にシリアルとハッシュの属性値の記録を保持するメカニズムを実装できます。次に、新しいアップデート通知ファイルを取得した後、頼るパーティは、以前に見られたシリアルのシリアル値とハッシュ値が新しくフェッチされたファイルのシリアルと一致する場合に比較する必要があります。違いが検出された場合、これはDeltaファイルが予期せず変異し、RPがセクション4に進む必要があることを意味します。" + }, + { + "indent": 0, + "text": "3.1. Example", + "section_title": true, + "ja": "3.1. 例" + }, + { + "indent": 3, + "text": "This section contains two versions of an Update Notification File to demonstrate an unexpected mutation. The initial Update Notification File is as follows:", + "ja": "このセクションには、予期しない突然変異を示すために、更新通知ファイルの2つのバージョンが含まれています。初期更新通知ファイルは次のとおりです。" + }, + { + "indent": 0, + "text": "\n\n\n\n\n\n\n Figure 1", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Based on the above Update Notification File, an RP implementation could record the following state:", + "ja": "上記の更新通知ファイルに基づいて、RP実装は次の状態を記録できます。" + }, + { + "indent": 0, + "text": "fe528335-db5f-48b2-be7e-bf0992d0b5ec\n1774 effac94afd30bbf1cd6e180e7f445a4d4653cb4c91068fa9e7b669d49b5aaa00\n1773 731169254dd5de0ede94ba6999bda63b0fae9880873a3710e87a71bafb64761a\n1772 d4087585323fd6b7fd899ebf662ef213c469d39f53839fa6241847f4f6ceb939\n\n Figure 2", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "A new version of the Update Notification File is published as follows:", + "ja": "更新通知ファイルの新しいバージョンは、次のように公開されています。" + }, + { + "indent": 0, + "text": "\n\n\n\n\n\n\n Figure 3", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Using its previously recorded state (see Figure 2), the RP can compare the hash values for serials 1773 and 1774. For serial 1774, compared to the earlier version of the Update Notification File, a different hash value is now listed, meaning an unexpected delta mutation occurred.", + "ja": "以前に記録された状態（図2を参照）を使用して、RPは、Serials 1773および1774のハッシュ値を比較できます。シリアル1774については、更新通知ファイルの以前のバージョンと比較して、別のハッシュ値がリストされています。デルタ変異が発生しました。" + }, + { + "indent": 0, + "text": "4. Recovery After Desynchronization", + "section_title": true, + "ja": "4. 非同期化後の回復" + }, + { + "indent": 3, + "text": "Following the detection of RRDP session desynchronization, in order to return to a synchronized state, RP implementations SHOULD issue a warning and SHOULD download the latest Snapshot File and process it as described in Section 3.4.3 of [RFC8182].", + "ja": "RRDPセッションの非同期化の検出後、同期状態に戻るために、RP実装は警告を発行し、[RFC8182]のセクション3.4.3で説明されているように最新のスナップショットファイルをダウンロードし、処理する必要があります。" + }, + { + "indent": 3, + "text": "See Section 6 for an overview of risks associated with desynchronization.", + "ja": "非同期化に関連するリスクの概要については、セクション6を参照してください。" + }, + { + "indent": 0, + "text": "5. Changes to RFC 8182", + "section_title": true, + "ja": "5. RFC 8182の変更" + }, + { + "indent": 3, + "text": "The following paragraph is added to Section 3.4.1 of [RFC8182], \"Processing the Update Notification File\", after the paragraph that ends \"The Relying Party MUST then download and process the Snapshot File specified in the downloaded Update Notification File as described in Section 3.4.3.\"", + "ja": "次の段落は[RFC8182]のセクション3.4.1に追加されます。「更新通知ファイルの処理」を終えた後、「依存者はダウンロードして、ダウンロードされた更新通知ファイルで指定されたスナップショットファイルをダウンロードして処理する必要があります。セクション3.4.3。」" + }, + { + "indent": 3, + "text": "NEW", + "ja": "新しい" + }, + { + "indent": 0, + "text": "If the session_id matches the last known session_id, the Relying Party SHOULD compare whether hash values associated with previously seen files for serials match the hash values of the corresponding serials in the newly fetched Update Notification File. If any differences are detected, this means that files were unexpectedly mutated (see [RFC9697]). The Relying Party SHOULD then download and process the Snapshot File specified in the downloaded Update Notification File as described in Section 3.4.3.", + "ja": "session_idが最後の既知のsession_idと一致する場合、頼るパーティは、シリアルの以前に見たファイルに関連付けられたハッシュ値を、新しくフェッチした更新通知ファイルの対応するシリアルのハッシュ値と一致するかどうかを比較する必要があります。違いが検出された場合、これはファイルが予期せず変異したことを意味します（[rfc9697]を参照）。次に、依存関係者は、セクション3.4.3で説明されているように、ダウンロードされた更新通知ファイルで指定されたスナップショットファイルをダウンロードして処理する必要があります。" + }, + { + "indent": 0, + "text": "6. Security Considerations", + "section_title": true, + "ja": "6. セキュリティに関する考慮事項" + }, + { + "indent": 3, + "text": "Due to the lifetime of RRDP sessions (often measured in months), desynchronization can persist for an extended period if undetected.", + "ja": "RRDPセッションの寿命（多くの場合数か月で測定）により、非同期は検出されない場合は長期間持続できます。" + }, + { + "indent": 3, + "text": "Caches in a desynchronized state pose a risk by emitting a different set of Validated Payloads than they would otherwise emit with a consistent repository copy. Through the interaction of the desynchronization and the _failed fetch_ mechanism described in Section 6.6 of [RFC9286], Relying Parties could spuriously omit Validated Payloads or emit Validated Payloads that the Certification Authority intended to withdraw. As a result, due to the desynchronized state, route decision making processes might consider route announcements intended to be marked valid as \"unknown\" or \"invalid\" for an indeterminate period.", + "ja": "非同期の状態のキャッシュは、一貫したリポジトリコピーで放出されるよりも異なる検証済みのペイロードを放出することにより、リスクをもたらします。[RFC9286]のセクション6.6に記載されている脱同期と_failed FETCH_メカニズムの相互作用により、当事者に依存することは、認定機関が撤回する予定の検証済みのペイロードを省略したり、検証済みのペイロードを発したりする可能性があります。その結果、非同期状態により、ルートの意思決定プロセスは、不確定期間にわたって「不明」または「無効」として有効であるとマークされることを目的としたルートアナウンスを検討する場合があります。" + }, + { + "indent": 3, + "text": "Missing Validated Payloads negatively impact the ability to validate BGP announcements using mechanisms such as those described in [RFC6811] and [ASPA].", + "ja": "検証済みのペイロードの欠落は、[RFC6811]や[ASPA]に記載されているメカニズムを使用してBGPアナウンスを検証する機能に悪影響を及ぼします。" + }, + { + "indent": 3, + "text": "Section 6.6 of [RFC9286] advises RP implementations to continue to use cached versions of objects, but only until such time as they become stale. By detecting whether the remote Repository Server is in an inconsistent state and then immediately switching to using the latest Snapshot File, RPs increase the probability to successfully replace objects before they become stale.", + "ja": "[RFC9286]のセクション6.6は、RPの実装に、キャッシュバージョンのオブジェクトの使用を継続することをアドバイスしますが、それらが古くなるまでのみです。リモートリポジトリサーバーが一貫性のない状態にあるかどうかを検出し、最新のスナップショットファイルの使用に直ちに切り替えると、RPSはオブジェクトが古くなる前に正常に交換する確率を高めます。" + }, + { + "indent": 0, + "text": "7. IANA Considerations", + "section_title": true, + "ja": "7. IANAの考慮事項" + }, + { + "indent": 3, + "text": "This document has no IANA actions.", + "ja": "このドキュメントにはIANAアクションがありません。" + }, + { + "indent": 0, + "text": "8. References", + "section_title": true, + "ja": "8. 参考文献" + }, + { + "indent": 0, + "text": "8.1. Normative References", + "section_title": true, + "ja": "8.1. 引用文献" + }, + { + "indent": 3, + "text": "[RFC2119] Bradner, S., \"Key words for use in RFCs to Indicate\n Requirement Levels\", BCP 14, RFC 2119,\n DOI 10.17487/RFC2119, March 1997,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8174] Leiba, B., \"Ambiguity of Uppercase vs Lowercase in RFC\n 2119 Key Words\", BCP 14, RFC 8174, DOI 10.17487/RFC8174,\n May 2017, .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein,\n \"The RPKI Repository Delta Protocol (RRDP)\", RFC 8182,\n DOI 10.17487/RFC8182, July 2017,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "8.2. Informative References", + "section_title": true, + "ja": "8.2. 参考引用" + }, + { + "indent": 3, + "text": "[ASPA] Azimov, A., Bogomazov, E., Bush, R., Patel, K., Snijders,\n J., and K. Sriram, \"BGP AS_PATH Verification Based on\n Autonomous System Provider Authorization (ASPA) Objects\",\n Work in Progress, Internet-Draft, draft-ietf-sidrops-aspa-\n verification-19, 27 September 2024,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.\n Austein, \"BGP Prefix Origin Validation\", RFC 6811,\n DOI 10.17487/RFC6811, January 2013,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC7115] Bush, R., \"Origin Validation Operation Based on the\n Resource Public Key Infrastructure (RPKI)\", BCP 185,\n RFC 7115, DOI 10.17487/RFC7115, January 2014,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "[RFC9286] Austein, R., Huston, G., Kent, S., and M. Lepinski,\n \"Manifests for the Resource Public Key Infrastructure\n (RPKI)\", RFC 9286, DOI 10.17487/RFC9286, June 2022,\n .", + "raw": true, + "ja": "" + }, + { + "indent": 0, + "text": "Acknowledgements", + "section_title": true, + "ja": "謝辞" + }, + { + "indent": 3, + "text": "During the hallway track at RIPE 86, Ties de Kock shared the idea for detecting this particular form of RRDP desynchronization, after which Claudio Jeker, Job Snijders, and Theo Buehler produced an implementation based on rpki-client. Equipped with tooling to detect this particular error condition, in subsequent months it became apparent that unexpected delta mutations in the global RPKI repositories do happen from time to time.", + "ja": "Ripe 86の廊下トラックで、Ties De Kockは、この特定の形式のRRDPデスンクロネ化を検出するためのアイデアを共有しました。この特定のエラー条件を検出するためのツールを装備して、その後数か月で、グローバルRPKIリポジトリの予期しないデルタ変異が時々起こることが明らかになりました。" + }, + { + "indent": 3, + "text": "The authors wish to thank Theo Buehler, Mikhail Puzanov, Alberto Leiva, Tom Harrison, Warren Kumari, Behcet Sarikaya, Murray Kucherawy, Éric Vyncke, Roman Danyliw, Tim Bruijnzeels, and Michael Hollyman for their careful review and feedback on this document.", + "ja": "著者は、Theo Buehler、Mikhail Puzanov、Alberto Leiva、Tom Harrison、Warren Kumari、Behcet Sarikaya、Murray Kucherawy、Eric Vyncke、Roman Danyliw、Timan Bruijnzeels、Michael Hollymanの慎重なレビューとこの文書のフィードバックに感謝したいと考えています。" + }, + { + "indent": 0, + "text": "Authors' Addresses", + "section_title": true, + "ja": "著者のアドレス" + }, + { + "indent": 3, + "text": "Job Snijders\nFastly\nAmsterdam\nNetherlands\nEmail: job@fastly.com", + "raw": true, + "ja": "" + }, + { + "indent": 3, + "text": "Ties de Kock\nRIPE NCC\nAmsterdam\nNetherlands\nEmail: tdekock@ripe.net", + "raw": true, + "ja": "" + } + ] +} \ No newline at end of file diff --git a/html/data-rfc-list.json b/html/data-rfc-list.json index be19d1140..9cdd2c3c0 100644 --- a/html/data-rfc-list.json +++ b/html/data-rfc-list.json @@ -43646,6 +43646,10 @@ "wg": "sidr" }, "8182": { + "upd_by": [ + "9674", + "9697" + ], "st": "Proposed Standard", "wg": "sidr" }, @@ -50689,6 +50693,9 @@ "st": "Proposed Standard", "wg": "uuidrev" }, + "9563": { + "st": "Informational" + }, "9564": { "st": "Informational" }, @@ -50920,6 +50927,10 @@ "st": "Proposed Standard", "wg": "lamps" }, + "9610": { + "st": "Proposed Standard", + "wg": "jmap" + }, "9611": { "st": "Proposed Standard", "wg": "ipsecme" @@ -51030,6 +51041,10 @@ "st": "Informational", "wg": "nvo3" }, + "9639": { + "st": "Proposed Standard", + "wg": "cellar" + }, "9640": { "st": "Proposed Standard", "wg": "netconf" @@ -51184,6 +51199,13 @@ "st": "Proposed Standard", "wg": "6man" }, + "9674": { + "upd": [ + "8182" + ], + "st": "Proposed Standard", + "wg": "sidrops" + }, "9675": { "st": "Informational", "wg": "dtn" @@ -51206,6 +51228,14 @@ "st": "Proposed Standard", "wg": "cbor" }, + "9683": { + "st": "Informational", + "wg": "rats" + }, + "9684": { + "st": "Proposed Standard", + "wg": "rats" + }, "9685": { "upd": [ "4861", @@ -51217,6 +51247,10 @@ "st": "Proposed Standard", "wg": "6lo" }, + "9686": { + "st": "Proposed Standard", + "wg": "dhc" + }, "9687": { "upd": [ "4271" @@ -51227,5 +51261,20 @@ "9688": { "st": "Proposed Standard", "wg": "lamps" + }, + "9689": { + "st": "Informational", + "wg": "teas" + }, + "9691": { + "st": "Proposed Standard", + "wg": "sidrops" + }, + "9697": { + "upd": [ + "8182" + ], + "st": "Proposed Standard", + "wg": "sidrops" } } \ No newline at end of file diff --git a/html/index.html b/html/index.html index ba2d7d95a..4ea57df9f 100644 --- a/html/index.html +++ b/html/index.html @@ -62,15 +62,30 @@

RFC文書を自動翻訳したページ一覧

+ + RFC 9697 - Detecting RPKI Repository Delta Protocol (RRDP) Session Desynchronization + + + RFC 9689 - Use Cases for a PCE as a Central Controller (PCECC) + RFC 9688 - Use of the SHA3 One-Way Hash Functions in the Cryptographic Message Syntax (CMS) RFC 9687 - Border Gateway Protocol 4 (BGP-4) Send Hold Timer + + RFC 9686 - Registering Self-Generated IPv6 Addresses Using DHCPv6 + RFC 9685 - Listener Subscription for IPv6 Neighbor Discovery Multicast and Anycast Addresses + + RFC 9684 - A YANG Data Model for Challenge-Response-Based Remote Attestation (CHARRA) Procedures Using Trusted Platform Modules (TPMs) + + + RFC 9683 - Remote Integrity Verification of Network Devices Containing Trusted Platform Modules + RFC 9682 - Updates to the Concise Data Definition Language (CDDL) Grammar @@ -86,6 +101,9 @@

RFC文書を自動翻訳したページ一覧

RFC 9675 - Delay-Tolerant Networking Management Architecture (DTNMA) + + RFC 9674 - Same-Origin Policy for the RPKI Repository Delta Protocol (RRDP) + RFC 9673 - IPv6 Hop-by-Hop Options Processing Procedures @@ -179,6 +197,9 @@

RFC文書を自動翻訳したページ一覧

RFC 9640 - YANG Data Types and Groupings for Cryptography + + RFC 9639 - Free Lossless Audio Codec (FLAC) + RFC 9638 - Network Virtualization over Layer 3 (NVO3) Encapsulation Considerations @@ -245,6 +266,9 @@

RFC文書を自動翻訳したページ一覧

RFC 9611 - Internet Key Exchange Protocol Version 2 (IKEv2) Support for Per‑Resource Child Security Associations (SAs) + + RFC 9610 - JSON Meta Application Protocol (JMAP) for Contacts + RFC 9608 - No Revocation Available for X.509 Public Key Certificates @@ -380,6 +404,9 @@

RFC文書を自動翻訳したページ一覧

RFC 9564 - Faster Than Light Speed Protocol (FLIP) + + RFC 9563 - SM2 Digital Signature Algorithm for DNSSEC + RFC 9562 - Universally Unique IDentifiers (UUIDs) diff --git a/html/rfc9563.html b/html/rfc9563.html new file mode 100644 index 000000000..7b15efedb --- /dev/null +++ b/html/rfc9563.html @@ -0,0 +1,1021 @@ + + + + + + RFC 9563 - SM2 Digital Signature Algorithm for DNSSEC 日本語訳 + + + + + + + + + + + + +
+
+ + + +
+
+
+ + +
+
+
+ 
+Independent Submission                                          C. Zhang
+Request for Comments: 9563                                        Y. Liu
+Category: Informational                                          F. Leng
+ISSN: 2070-1721                                                  Q. Zhao
+                                                                   Z. He
+                                                                   CNNIC
+                                                           December 2024
+
+
+
+
+
+
+SM2 Digital Signature Algorithm for DNSSEC +
+
+
+
+DNSSECのSM2デジタル署名アルゴリズム +
+
+
+
+
+
+Abstract +
+
+
+
+概要 +
+
+
+
+
+

+This document specifies the use of the SM2 digital signature algorithm and SM3 hash algorithm for DNS Security (DNSSEC). +

+
+
+

+このドキュメントは、DNSセキュリティ（DNSSEC）にSM2デジタル署名アルゴリズムとSM3ハッシュアルゴリズムの使用を指定しています。 +

+
+
+
+
+

+This document is an Independent Submission to the RFC series and does not have consensus of the IETF community. +

+
+
+

+このドキュメントは、RFCシリーズへの独立した提出であり、IETFコミュニティのコンセンサスはありません。 +

+
+
+
+
+
+Status of This Memo +
+
+
+
+本文書の位置付け +
+
+
+
+
+

+This document is not an Internet Standards Track specification; it is published for informational purposes. +

+
+
+

+このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。 +

+
+
+
+
+

+This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841. +

+
+
+

+これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。RFCエディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。RFCエディターによって公開されることが承認されたドキュメントは、インターネット標準のレベルの候補者ではありません。see Section 2 of RFC 7841. +

+
+
+
+
+

+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/rfc9563. +

+
+
+

+このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9563で取得できます。 +

+
+
+
+
+
+Copyright Notice +
+
+
+
+著作権表示 +
+
+
+
+
+

+Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. +

+
+
+

+著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。 +

+
+
+
+
+

+This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. +

+
+
+

+このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。 +

+
+
+
+
+
+Table of Contents +
+
+
+
+目次 +
+
+
+
+
+ 
+   1.  Introduction
+   2.  SM3 DS Records
+   3.  SM2 Parameters
+   4.  DNSKEY and RRSIG Resource Records for SM2
+     4.1.  DNSKEY Resource Records
+     4.2.  RRSIG Resource Records
+   5.  Support for NSEC3 Denial of Existence
+   6.  Example
+   7.  IANA Considerations
+   8.  Security Considerations
+   9.  References
+     9.1.  Normative References
+     9.2.  Informative References
+   Authors' Addresses
+
+
+
+
+
+
+1. Introduction +
+
+
+
+1. はじめに +
+
+
+
+
+

+DNSSEC is broadly defined in [RFC4033], [RFC4034], and [RFC4035]. It uses cryptographic keys and digital signatures to provide authentication of DNS data. DNSSEC signature algorithms are registered in the DNSSEC algorithm numbers registry [IANA]. +

+
+
+

+DNSSECは、[RFC4033]、[RFC4034]、および[RFC4035]で広く定義されています。暗号化キーとデジタル署名を使用して、DNSデータの認証を提供します。DNSSEC署名アルゴリズムは、DNSSECアルゴリズム番号レジストリ[IANA]に登録されています。 +

+
+
+
+
+

+This document defines the DNSKEY and RRSIG resource records (RRs) of new signing algorithms: SM2 uses elliptic curves over 256-bit prime fields with SM3 hash algorithm. (A description of SM2 can be found in GM/T 0003.2-2012 [GMT-0003.2] or ISO/IEC14888-3:2018 [ISO-IEC14888-3_2018], and a description of SM3 can be found in GM/T 0004-2012 [GMT-0004] or ISO/IEC10118-3:2018 [ISO-IEC10118-3_2018].) This document also defines the DS RR for the SM3 one-way hash algorithm. In the signing algorithm defined in this document, the size of the key for the elliptic curve is matched with the size of the output of the hash algorithm. Both are 256 bits. +

+
+
+

+このドキュメントでは、新しい署名アルゴリズム：SM2のDNSKEYおよびRRSIGリソースレコード（RRS）を定義します。SM2は、SM3ハッシュアルゴリズムを備えた256ビットプライムフィールドに楕円曲線を使用します。（SM2の説明は、GM/T 0003.2-2012 [GMT-0003.2]またはISO/IEC14888-3：2018 [ISO-IEC14888-3_2018]にあり、SM3の説明はGM/T 0004-にあります。2012 [GMT-0004]またはISO/IEC10118-3：2018 [ISO-IEC10118-3_2018]。）このドキュメントは、SM3一方向ハッシュアルゴリズムのDS RRも定義しています。このドキュメントで定義されている署名アルゴリズムでは、楕円曲線のキーのサイズは、ハッシュアルゴリズムの出力のサイズと一致します。どちらも256ビットです。 +

+
+
+
+
+

+Many implementations may not support SM2 signatures and SM3 digests. Section 5.2 of [RFC6840] specifies handling of answers in such cases. +

+
+
+

+多くの実装は、SM2署名とSM3ダイジェストをサポートしていない場合があります。[RFC6840]のセクション5.2は、そのような場合の回答の処理を指定しています。 +

+
+
+
+
+

+Caution: This specification is not a standard and does not have IETF community consensus. It makes use of cryptographic algorithms that are national standards for China, as well as ISO/IEC standards (ISO/ IEC 14888:3-2018 [ISO-IEC14888-3_2018] and ISO/IEC 10118:3-2018 [ISO-IEC10118-3_2018]). Neither the IETF nor the IRTF has analyzed that algorithm for suitability for any given application, and it may contain either intended or unintended weaknesses. +

+
+
+

+注意：この仕様は標準ではなく、IETFコミュニティのコンセンサスはありません。中国の国家基準である暗号化アルゴリズム、およびISO/IEC標準（ISO/IEC 14888：3-2018 [ISO-IEC14888-3_2018]およびISO/IEC 10118：3-2018 [ISO-IEC10118-3_2018]）。IETFもIRTFも、そのアルゴリズムを特定のアプリケーションへの適合性について分析しておらず、意図されたまたは意図しない弱点のいずれかを含む場合があります。 +

+
+
+
+
+

+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. +

+
+
+

+キーワード「必須」、「必要」、「必須」、「shall」、「shall」、「shill "of"、 "nove"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。 +

+
+
+
+
+
+2. SM3 DS Records +
+
+
+
+2. SM3 DSレコード +
+
+
+
+
+

+The implementation of SM3 in DNSSEC follows the implementation of SHA-256 as specified in [RFC4509] except that the underlying algorithm is SM3 with digest type code 6. +

+
+
+

+DNSSECでのSM3の実装は、[RFC4509]で指定されているSHA-256の実装に続きます。 +

+
+
+
+
+

+The generation of an SM3 hash value is described in Section 5 of [GMT-0004] and generates a 256-bit hash value. +

+
+
+

+SM3ハッシュ値の生成は、[GMT-0004]のセクション5で説明されており、256ビットハッシュ値を生成します。 +

+
+
+
+
+
+3. SM2 Parameters +
+
+
+
+3. SM2パラメーター +
+
+
+
+
+

+Verifying SM2 signatures requires agreement between the signer and the verifier on the parameters used. The SM2 digital signature algorithm has been added to [ISO-IEC14888-3_2018]. The parameters of the curve used in this profile are as follows: +

+
+
+

+SM2の署名を確認するには、使用されるパラメーターの署名者と検証者との間の合意が必要です。SM2デジタル署名アルゴリズムが[ISO-IEC14888-3_2018]に追加されました。このプロファイルで使用される曲線のパラメーターは次のとおりです。 +

+
+
+
+
+ 
+   p  = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF
+        FFFFFFFF 00000000 FFFFFFFF FFFFFFFF
+   a  = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF
+        FFFFFFFF 00000000 FFFFFFFF FFFFFFFC
+   b  = 28E9FA9E 9D9F5E34 4D5A9E4B CF6509A7
+        F39789F5 15AB8F92 DDBCBD41 4D940E93
+   xG = 32C4AE2C 1F198119 5F990446 6A39C994
+        8FE30BBF F2660BE1 715A4589 334C74C7
+   yG = BC3736A2 F4F6779C 59BDCEE3 6B692153
+        D0A9877C C62A4740 02DF32E5 2139F0A0
+   n  = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF
+        7203DF6B 21C6052B 53BBF409 39D54123
+
+
+
+
+
+
+4. DNSKEY and RRSIG Resource Records for SM2 +
+
+
+
+4. SM2のDNSKEYおよびRRSIGリソースレコード +
+
+
+
+
+
+4.1. DNSKEY Resource Records +
+
+
+
+4.1. DNSKEYリソースレコード +
+
+
+
+
+

+SM2 public keys consist of a single value, called "P". In DNSSEC keys, P is a string of 64 octets that represents the uncompressed form of a curve point, "x | y". (Conversion of a point to an octet string is described in Section 4.2.8 of [GMT-0003.1].) +

+
+
+

+SM2パブリックキーは、「P」と呼ばれる単一の値で構成されています。DNSSECキーでは、Pは64個のオクテットの文字列であり、「x | y」の曲線ポイントの非圧縮形式を表します。（ポイントのオクテット文字列への変換は、[GMT-0003.1]のセクション4.2.8で説明されています。） +

+
+
+
+
+
+4.2. RRSIG Resource Records +
+
+
+
+4.2. RRSIGリソースレコード +
+
+
+
+
+

+The SM2 signature is the combination of two non-negative integers, called "r" and "s". The two integers, each of which is formatted as a simple octet string, are combined into a single longer octet string for DNSSEC as the concatenation "r | s". (Conversion of the integers to bit strings is described in Section 4.2.1 of [GMT-0003.1].) Each integer MUST be encoded as 32 octets. +

+
+
+

+SM2署名は、「R」と「S」と呼ばれる2つの非陰性整数の組み合わせです。それぞれが単純なオクテット弦としてフォーマットされている2つの整数は、連結「r | s」としてDNSSECの長いオクテット文字列に結合されます。（整数の弦への変換は、[GMT-0003.1]のセクション4.2.1で説明されています。）各整数は32オクテットとしてエンコードする必要があります。 +

+
+
+
+
+

+Process details are described in Section 6 of [GMT-0003.2]. +

+
+
+

+プロセスの詳細は、[GMT-0003.2]のセクション6で説明されています。 +

+
+
+
+
+

+The algorithm number associated with the DNSKEY and RRSIG resource records is 17, which is described in the IANA Considerations section. +

+
+
+

+DNSKEYおよびRRSIGリソースレコードに関連付けられたアルゴリズム番号は17で、IANAの考慮事項セクションで説明されています。 +

+
+
+
+
+

+Conformant implementations that create records to be put into the DNS MAY implement signing and verification for the SM2 digital signature algorithm. Conformant DNSSEC verifiers MAY implement verification for the above algorithm. +

+
+
+

+DNSに配置されるレコードを作成する適合実装は、SM2デジタル署名アルゴリズムの署名と検証を実装する場合があります。コンフォーマントDNSSEC検証は、上記のアルゴリズムの検証を実装する場合があります。 +

+
+
+
+
+
+5. Support for NSEC3 Denial of Existence +
+
+
+
+5. NSEC3存在の拒否のサポート +
+
+
+
+
+

+This document does not define algorithm aliases mentioned in [RFC5155]. +

+
+
+

+このドキュメントは、[RFC5155]で言及されているアルゴリズムエイリアスを定義しません。 +

+
+
+
+
+

+A DNSSEC validator that implements the signing algorithms defined in this document MUST be able to validate negative answers in the form of both NSEC and NSEC3 with hash algorithm SHA-1, as defined in [RFC5155]. An authoritative server that does not implement NSEC3 MAY still serve zones that use the signing algorithms defined in this document with NSEC denial of existence. +

+
+
+

+[RFC5155]で定義されているように、このドキュメントで定義されている署名アルゴリズムを実装するDNSSECバリエーターは、ハッシュアルゴリズムSHA-1を使用してNSECとNSEC3の両方の形で否定的な答えを検証できる必要があります。NSEC3を実装していない権威あるサーバーは、NSECの存在拒否を伴うこのドキュメントで定義されている署名アルゴリズムを使用するゾーンを依然として提供する場合があります。 +

+
+
+
+
+

+If using NSEC3, the iterations MUST be 0 and salt MUST be an empty string as recommended in Section 3.1 of [RFC9276]. +

+
+
+

+NSEC3を使用する場合、反復は0でなければならず、[RFC9276]のセクション3.1で推奨されるように、塩は空の文字列でなければなりません。 +

+
+
+
+
+
+6. Example +
+
+
+
+6. 例 +
+
+
+
+
+

+The following is an example of SM2 keys and signatures in DNS zone file format, including DNSKEY RR, NSEC3PARAM RR, NSEC3 RR with RRSIG RRs, and DS RR. +

+
+
+

+以下は、DNSKEY RR、NSEC3PARAM RR、RRSIG RRSを備えたNSEC3 RR、DS RRを含むDNSゾーンファイル形式のSM2キーと署名の例です。 +

+
+
+
+
+ 
+   Private-key-format: v1.3
+   Algorithm: 17 (SM2SM3)
+   PrivateKey: V24tjJgXxp2ykscKRZdT+iuR5J1xRQN+FKoQACmo9fA=
+
+   example. 3600 IN DS 27215 17 6 (
+      86671f82dd872e4ee73647a95dff7fd0af599ff8a43f fa26c9a2593091653c0e
+      )
+
+   example. 3600  IN   DNSKEY  256 3 17 (
+       7EQ32PTAp+1ac6R9Ze2nfB8pPc2OJqkHSjug
+       ALr4SuD9awuQxhfw7wMpiXv7JK4/VwwTrCxJ
+       wu+qUuDsgoBK4w==
+       ) ; ZSK; alg = SM2SM3 ; key id = 65042
+   example. 3600  IN   RRSIG   DNSKEY 17 1 3600 (
+       20230901000000 20220901000000 65042 example.
+       lF2eq49e62Nn4aT5x8ZI6PdRSTPHPDixZdyl
+       lM6GWu4lkRWkpTgWLE4lQK/+qHdNS4DdTd36
+       Jsuu0FSO5k48Qg== )
+
+   example. 0  IN   NSEC3PARAM 1 0 10 AABBCCDD
+   example. 0  IN   RRSIG    NSEC3PARAM 17 1 0 (
+          20230901000000 20220901000000 65042 example.
+          aqntwEYEJzkVb8SNuJLwdx7f+vivv5IUIeAj )
+
+   62KP1QB93KRGR6LM7SEVPJVNG90BLUE8.example. 3600 IN NSEC3  1 1 10
+       AABBCCDD (
+       GTGVQIILTSSJ8FFO9J6DC8PRTFAEA8G2 NS SOA RRSIG DNSKEY NSEC3PARAM )
+
+   62KP1QB93KRGR6LM7SEVPJVNG90BLUE8.example. 3600 IN RRSIG  NSEC3 17 2
+       3600 (
+       20230901000000 20220901000000 65042 example.
+       FOWLegTgFkFY9vCOo4kHwjEvZ+IL1NMl4s9V
+       hVyPOwokd5uOLKeXTP19HIeEtW73WcJ9XNe/ ie/knp7Edo/hxw== )
+
+
+
+
+
+

+[Example_Program] is an example program based on dnspython and gmssl, which supplies key generating, zone signing, zone validating, and DS RR generating functions for convenience. +

+
+
+

+[example_program]は、dnspythonとgmsslに基づく例プログラムであり、キー生成、ゾーン署名、ゾーン検証、およびDS RR生成機能を提供します。 +

+
+
+
+
+
+7. IANA Considerations +
+
+
+
+7. IANAの考慮事項 +
+
+
+
+
+

+IANA has registered the following in the "Digest Algorithms" registry within the "DNSSEC Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms" registry group. +

+
+
+

+IANAは、「DNSSEC Delogation Signer（DS）Resource Record（RR）Type Digest Algorithms」レジストリグループ内の「Digestアルゴリズム」レジストリに次のことを登録しました。 +

+
+
+
+
+ 
+                  +=======+=============+==========+===============+
+                  | Value | Digest Type | Status   | Reference     |
+                  +=======+=============+==========+===============+
+                  | 6     | SM3         | OPTIONAL | This document |
+                  +-------+-------------+----------+---------------+
+
+                                       Table 1
+
+
+
+
+
+

+IANA has registered the following in the "DNS Security Algorithm Numbers" registry within the "Domain Name System Security (DNSSEC) Algorithm Numbers" registry group. +

+
+
+

+IANAは、「ドメイン名システムセキュリティ（DNSSEC）アルゴリズム番号」レジストリグループ内の「DNSセキュリティアルゴリズム番号」レジストリに以下を登録しました。 +

+
+
+
+
+ 
++========+================+==========+=========+========+===========+
+| Number | Description    | Mnemonic | Zone    | Trans. | Reference |
+|        |                |          | Signing | Sec.   |           |
++========+================+==========+=========+========+===========+
+| 17     | SM2 signing    | SM2SM3   | Y       | *      | This      |
+|        | algorithm      |          |         |        | document  |
+|        | with SM3       |          |         |        |           |
+|        | hashing        |          |         |        |           |
+|        | algorithm      |          |         |        |           |
++--------+----------------+----------+---------+--------+-----------+
+
+                               Table 2
+
+
+
+
+
+

+* There has been no determination of standardization of the use of this algorithm with Transaction Security. +

+
+
+

+* トランザクションセキュリティを備えたこのアルゴリズムの使用の標準化の決定はありませんでした。 +

+
+
+
+
+
+8. Security Considerations +
+
+
+
+8. セキュリティに関する考慮事項 +
+
+
+
+
+

+The security strength of SM2 depends on the size of the key. A longer key provides stronger security strength. The security of ECC-based algorithms is influenced by the curve it uses, too. +

+
+
+

+SM2のセキュリティ強度は、キーのサイズに依存します。より長いキーは、より強力なセキュリティ強度を提供します。ECCベースのアルゴリズムのセキュリティは、使用する曲線の影響を受けます。 +

+
+
+
+
+

+Like any cryptographic algorithm, it may come to pass that a weakness is found in either SM2 or SM3. In this case, the proper remediation is crypto-agility. In the case of DNSSEC, the appropriate approach would be to regenerate appropriate DS, DNSKEY, RRSIG, and NSEC3 records. Care MUST be taken in this situation to permit appropriate rollovers, taking into account record caching. See [RFC7583] for details. A suitable replacement algorithm should be both widely implemented and not known to have weaknesses. +

+
+
+

+他の暗号化アルゴリズムと同様に、SM2またはSM3のいずれかで弱点が見られることが合格する可能性があります。この場合、適切な修復は暗号特性です。DNSSECの場合、適切なアプローチは、適切なDS、DNSKEY、RRSIG、およびNSEC3レコードを再生することです。この状況では、記録的なキャッシングを考慮して、適切なロールオーバーを許可するように注意する必要があります。詳細については、[RFC7583]を参照してください。適切な交換アルゴリズムは、広く実装されており、弱点があることが知られていない必要があります。 +

+
+
+
+
+

+The security considerations listed in [RFC4509] apply here as well. +

+
+
+

+[RFC4509]にリストされているセキュリティ上の考慮事項もここにも適用されます。 +

+
+
+
+
+
+9. References +
+
+
+
+9. 参考文献 +
+
+
+
+
+
+9.1. Normative References +
+
+
+
+9.1. 引用文献 +
+
+
+
+
+ 
+   [GMT-0003.1]
+              Cryptography Standardization Technical Committee of China,
+              "SM2 Public Key Cryptographic Algorithms Based on Elliptic
+              Curves Part 1: General", [In Chinese], GM/T 0003.1-2012,
+              March 2012.  English translation available at:
+              http://www.gmbz.org.cn/
+              upload/2024-11-18/1731899501687024253.pdf
+
+
+
+
+
+ 
+   [GMT-0003.2]
+              Cryptography Standardization Technical Committee of China,
+              "SM2 Public Key Cryptographic Algorithms Based on Elliptic
+              Curves Part 2: Digital Signature Algorithm", [In Chinese],
+              GM/T 0003.2-2012, March 2012.  English translation
+              available at: http://www.gmbz.org.cn/
+              upload/2024-11-18/1731899583359013934.pdf
+
+
+
+
+
+ 
+   [GMT-0004] Cryptography Standardization Technical Committee of China,
+              "SM3 Cryptographic Hash Algorithm", [In Chinese], GM/
+              T 0004-2012, March 2012.  English translation available
+              at: http://www.gmbz.org.cn/
+              upload/2024-11-18/1731899426565012428.pdf.
+
+
+
+
+
+ 
+   [IANA]     IANA, "DNS Security Algorithm Numbers",
+              <https://www.iana.org/assignments/dns-sec-alg-numbers>.
+
+
+
+
+
+ 
+   [ISO-IEC10118-3_2018]
+              ISO/IEC, "IT Security techniques -- Hash-functions -- Part
+              3: Dedicated hash-functions", ISO/IEC 10118-3:2018,
+              October 2018.
+
+
+
+
+
+ 
+   [ISO-IEC14888-3_2018]
+              ISO/IEC, "IT Security techniques -- Digital signatures
+              with appendix -- Part 3: Discrete logarithm based
+              mechanisms", ISO/IEC 14888-3:2018, November 2018.
+
+
+
+
+
+ 
+   [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>.
+
+
+
+
+
+ 
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements",
+              RFC 4033, DOI 10.17487/RFC4033, March 2005,
+              <https://www.rfc-editor.org/info/rfc4033>.
+
+
+
+
+
+ 
+   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Resource Records for the DNS Security Extensions",
+              RFC 4034, DOI 10.17487/RFC4034, March 2005,
+              <https://www.rfc-editor.org/info/rfc4034>.
+
+
+
+
+
+ 
+   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Protocol Modifications for the DNS Security
+              Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
+              <https://www.rfc-editor.org/info/rfc4035>.
+
+
+
+
+
+ 
+   [RFC4509]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
+              (DS) Resource Records (RRs)", RFC 4509,
+              DOI 10.17487/RFC4509, May 2006,
+              <https://www.rfc-editor.org/info/rfc4509>.
+
+
+
+
+
+ 
+   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
+              Security (DNSSEC) Hashed Authenticated Denial of
+              Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
+              <https://www.rfc-editor.org/info/rfc5155>.
+
+
+
+
+
+ 
+   [RFC6840]  Weiler, S., Ed. and D. Blacka, Ed., "Clarifications and
+              Implementation Notes for DNS Security (DNSSEC)", RFC 6840,
+              DOI 10.17487/RFC6840, February 2013,
+              <https://www.rfc-editor.org/info/rfc6840>.
+
+
+
+
+
+ 
+   [RFC7583]  Morris, S., Ihren, J., Dickinson, J., and W. Mekking,
+              "DNSSEC Key Rollover Timing Considerations", RFC 7583,
+              DOI 10.17487/RFC7583, October 2015,
+              <https://www.rfc-editor.org/info/rfc7583>.
+
+
+
+
+
+ 
+   [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>.
+
+
+
+
+
+ 
+   [RFC9276]  Hardaker, W. and V. Dukhovni, "Guidance for NSEC3
+              Parameter Settings", BCP 236, RFC 9276,
+              DOI 10.17487/RFC9276, August 2022,
+              <https://www.rfc-editor.org/info/rfc9276>.
+
+
+
+
+
+
+9.2. Informative References +
+
+
+
+9.2. 参考引用 +
+
+
+
+
+ 
+   [Example_Program]
+              "sign and validate dnssec signature with sm2sm3
+              algorithm", commit 6f98c17, April 2023,
+              <https://github.com/scooct/dnssec_sm2sm3>.
+
+
+
+
+
+
+Authors' Addresses +
+
+
+
+著者のアドレス +
+
+
+
+
+ 
+   Cuiling Zhang
+   CNNIC
+   No.4 South 4th Street, Zhongguancun
+   Beijing
+   100190
+   China
+   Email: zhangcuiling@cnnic.cn
+
+
+
+
+
+ 
+   Yukun Liu
+   CNNIC
+   No.4 South 4th Street, Zhongguancun
+   Beijing
+   100190
+   China
+   Email: liuyukun@cnnic.cn
+
+
+
+
+
+ 
+   Feng Leng
+   CNNIC
+   No.4 South 4th Street, Zhongguancun
+   Beijing
+   100190
+   China
+   Email: lengfeng@cnnic.cn
+
+
+
+
+
+ 
+   Qi Zhao
+   CNNIC
+   No.4 South 4th Street, Zhongguancun
+   Beijing
+   100190
+   China
+   Email: zhaoqi@cnnic.cn
+
+
+
+
+
+ 
+   Zheng He
+   CNNIC
+   No.4 South 4th Street, Zhongguancun
+   Beijing
+   100190
+   China
+   Email: hezh@cnnic.cn
+
+
+
+
+ + + diff --git a/html/rfc9610.html b/html/rfc9610.html new file mode 100644 index 000000000..80870dcb9 --- /dev/null +++ b/html/rfc9610.html @@ -0,0 +1,3673 @@ + + + + + + RFC 9610 - JSON Meta Application Protocol (JMAP) for Contacts 日本語訳 + + + + + + + + + + + + +
+
+ + + +
+
+
+ + +
+
+
+ 
+Internet Engineering Task Force (IETF)                   N. Jenkins, Ed.
+Request for Comments: 9610                                      Fastmail
+Category: Standards Track                                  December 2024
+ISSN: 2070-1721
+
+
+
+
+
+
+JSON Meta Application Protocol (JMAP) for Contacts +
+
+
+
+連絡先用のJSONメタアプリケーションプロトコル（JMAP） +
+
+
+
+
+
+Abstract +
+
+
+
+概要 +
+
+
+
+
+

+This document specifies a data model for synchronising contact data with a server using the JSON Meta Application Protocol (JMAP). +

+
+
+

+このドキュメントは、JSON Metaアプリケーションプロトコル（JMAP）を使用してサーバーと連絡先データを同期するためのデータモデルを指定します。 +

+
+
+
+
+
+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/rfc9610. +

+
+
+

+このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9610で取得できます。 +

+
+
+
+
+
+Copyright Notice +
+
+
+
+著作権表示 +
+
+
+
+
+

+Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. +

+
+
+

+著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。 +

+
+
+
+
+

+This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. +

+
+
+

+このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。 +

+
+
+
+
+
+Table of Contents +
+
+
+
+目次 +
+
+
+
+
+ 
+   1.  Introduction
+     1.1.  Notational Conventions
+     1.2.  Terminology
+     1.3.  Data Model Overview
+     1.4.  Addition to the Capabilities Object
+       1.4.1.  urn:ietf:params:jmap:contacts
+   2.  AddressBooks
+     2.1.  AddressBook/get
+     2.2.  AddressBook/changes
+     2.3.  AddressBook/set
+   3.  ContactCards
+     3.1.  ContactCard/get
+     3.2.  ContactCard/changes
+     3.3.  ContactCard/query
+       3.3.1.  Filtering
+       3.3.2.  Sorting
+     3.4.  ContactCard/queryChanges
+     3.5.  ContactCard/set
+     3.6.  ContactCard/copy
+   4.  Examples
+     4.1.  Fetching Initial Data
+     4.2.  Changing the Default Address Book
+   5.  Internationalisation Considerations
+   6.  Security Considerations
+   7.  IANA Considerations
+     7.1.  JMAP Capability Registration for "contacts"
+     7.2.  JMAP Data Type Registration for "AddressBook"
+     7.3.  JMAP Data Type Registration for "ContactCard"
+     7.4.  JMAP Error Codes Registry
+       7.4.1.  addressBookHasContents
+     7.5.  JSContact Property Registrations
+       7.5.1.  id
+       7.5.2.  addressBookIds
+       7.5.3.  blobId
+   8.  References
+     8.1.  Normative References
+     8.2.  Informative References
+   Author's Address
+
+
+
+
+
+
+1. Introduction +
+
+
+
+1. はじめに +
+
+
+
+
+

+The JSON Meta Application Protocol (JMAP) [RFC8620] is a generic protocol for synchronising data, such as mail, calendars, or contacts, between a client and a server. It is optimised for mobile and web environments and aims to provide a consistent interface to different data types. +

+
+
+

+JSON Meta Application Protocol（JMAP）[RFC8620]は、クライアントとサーバー間のメール、カレンダー、連絡先などのデータを同期するための一般的なプロトコルです。モバイルおよびWeb環境向けに最適化されており、さまざまなデータ型に一貫したインターフェイスを提供することを目的としています。 +

+
+
+
+
+

+This specification defines a data model for synchronising contacts between a client and a server using JMAP. +

+
+
+

+この仕様は、JMAPを使用してクライアントとサーバー間の連絡先を同期するためのデータモデルを定義します。 +

+
+
+
+
+
+1.1. Notational Conventions +
+
+
+
+1.1. 表記規則 +
+
+
+
+
+

+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. +

+
+
+

+「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。 +

+
+
+
+
+

+Type signatures, examples, and property descriptions in this document follow the conventions established in Section 1.1 of [RFC8620]. The Id, UnsignedInt, and UTCDate data types defined in Sections 1.2, 1.3, and 1.4 of [RFC8620] are also used in this document. +

+
+
+

+このドキュメントのタイプシグネチャ、例、およびプロパティの説明は、[RFC8620]のセクション1.1で確立された規則に従っています。[RFC8620]のセクション1.2、1.3、および1.4で定義されているID、UnsignedInt、およびUTCDATEデータ型も、このドキュメントで使用されています。 +

+
+
+
+
+
+1.2. Terminology +
+
+
+
+1.2. 用語 +
+
+
+
+
+

+The same terminology used in the core JMAP specification (see Section 1.6 of [RFC8620]) is also used in this document. +

+
+
+

+このドキュメントでは、コアJMAP仕様（[RFC8620]のセクション1.6を参照）で使用されているのと同じ用語も使用されています。 +

+
+
+
+
+

+The terms AddressBook and ContactCard (with these specific capitalizations) are used to refer to the data types defined in this document and instances of those data types. +

+
+
+

+アドレスブックとコンタクトカード（これらの特定の大文字を使用）は、このドキュメントで定義されているデータ型とそれらのデータ型のインスタンスを参照するために使用されます。 +

+
+
+
+
+
+1.3. Data Model Overview +
+
+
+
+1.3. データモデルの概要 +
+
+
+
+
+

+An Account (see Section 1.6.2 of [RFC8620]) with support for the contact data model contains zero or more AddressBook objects, which is a named collection of zero or more ContactCards. A ContactCard is a representation of a person, company, entity, or a group of such entities in JSContact Card format, as defined in Section 2 of [RFC9553]. Each ContactCard belongs to one or more AddressBooks. +

+
+
+

+連絡先データモデルのサポートを備えたアカウント（[RFC8620]のセクション1.6.2を参照）には、ゼロ以上のアドレスブックオブジェクトが含まれています。コンタクトカードとは、[RFC9553]のセクション2で定義されているように、JSCONTACTカード形式の個人、会社、エンティティ、またはそのようなエンティティのグループの表現です。各コンタクトカードは、1つ以上のアドレスブックに属します。 +

+
+
+
+
+

+In servers with support for JMAP Sharing [RFC9670], users may see and configure sharing of contact data with others. Sharing permissions are managed per AddressBook. +

+
+
+

+JMAP共有[RFC9670]をサポートするサーバーでは、ユーザーは他の人と連絡先データの共有を見て構成することができます。共有権限は、アドレスブックごとに管理されます。 +

+
+
+
+
+
+1.4. Addition to the Capabilities Object +
+
+
+
+1.4. 機能オブジェクトに加えます +
+
+
+
+
+

+The capabilities object is returned as part of the JMAP Session object; see Section 2 of [RFC8620]. This document defines one additional capability URI. +

+
+
+

+機能オブジェクトは、JMAPセッションオブジェクトの一部として返されます。[RFC8620]のセクション2を参照してください。このドキュメントでは、1つの追加の機能URIを定義します。 +

+
+
+
+
+
+1.4.1. urn:ietf:params:jmap:contacts +
+
+
+
+1.4.1. urn：ietf：params：jmap：連絡先 +
+
+
+
+
+

+This represents support for the AddressBook and ContactCard data types and associated API methods. The value of this property in the JMAP Session "capabilities" property is an empty object. +

+
+
+

+これは、アドレスブックおよび連絡先データ型および関連するAPIメソッドのサポートを表しています。JMAPセッション「機能」プロパティのこのプロパティの値は、空のオブジェクトです。 +

+
+
+
+
+

+The value of this property in an account's "accountCapabilities" property is an object that MUST contain the following information on server capabilities and permissions for that account: +

+
+
+

+アカウントの「accountcapability」プロパティ内のこのプロパティの値は、そのアカウントのサーバー機能と許可に関する次の情報を含める必要があるオブジェクトです。 +

+
+
+
+
+

+*maxAddressBooksPerCard*: UnsignedInt|null +

+
+
+

+*maxaddressbookspercard*：unsignedint | null +

+
+
+
+
+

+The maximum number of AddressBooks (see Section 2) that can be assigned to a single ContactCard object (see Section 3). This MUST be an integer >= 1, or null for no limit (or rather, the limit is always the number of AddressBooks in the account). +

+
+
+

+単一のコンタクトカードオブジェクト（セクション3を参照）に割り当てることができるアドレスブックの最大数（セクション2を参照）。これは整数> = 1、または制限なしでnullでなければなりません（または、制限は常にアカウント内のアドレスブックの数です）。 +

+
+
+
+
+

+*mayCreateAddressBook*: Boolean +

+
+
+

+*maycreateaddressbook*：boolean +

+
+
+
+
+

+The user may create an AddressBook in this account if, and only if, this is true. +

+
+
+

+ユーザーは、このアカウントにアドレスブックを作成する場合があります。 +

+
+
+
+
+
+2. AddressBooks +
+
+
+
+2. アドレス帳 +
+
+
+
+
+

+An AddressBook is a named collection of ContactCards. All ContactCards are associated with one or more AddressBooks. +

+
+
+

+アドレスブックは、コンタクトカードの名前が付けられたコレクションです。すべてのコンタクトカードは、1つ以上のアドレスブックに関連付けられています。 +

+
+
+
+
+

+An *AddressBook* object has the following properties: +

+
+
+

+*アドレスブック *オブジェクトには次のプロパティがあります。 +

+
+
+
+
+

+*id*: Id (immutable; server-set) +

+
+
+

+*id*：id（inmutable; server-set） +

+
+
+
+
+

+The id of the AddressBook. +

+
+
+

+アドレスブックのID。 +

+
+
+
+
+

+*name*: String +

+
+
+

+*名前*：文字列 +

+
+
+
+
+

+The user-visible name of the AddressBook. This MUST NOT be the empty string and MUST NOT be greater than 255 octets in size when encoded as UTF-8. +

+
+
+

+アドレスブックのユーザー可視名。これは空の文字列であってはならず、UTF-8としてエンコードされた場合、サイズが255オクテットを超えてはなりません。 +

+
+
+
+
+

+*description*: String|null (default: null) +

+
+
+

+*説明*：string | null（デフォルト：null） +

+
+
+
+
+

+An optional long-form description of the AddressBook that provides context in shared environments where users need more than just the name. +

+
+
+

+ユーザーが名前以上のものを必要とする共有環境でコンテキストを提供するアドレスブックのオプションの長い形式の説明。 +

+
+
+
+
+

+*sortOrder*: UnsignedInt (default: 0) +

+
+
+

+*SORTORDER*：unsignedint（デフォルト：0） +

+
+
+
+
+

+Defines the sort order of AddressBooks when presented in the client's UI so it is consistent between devices. The number MUST be an integer in the range 0 <= sortOrder < 2^31. +

+
+
+

+クライアントのUIで提示されたときにアドレス帳の並べ替え順序を定義して、デバイス間で一貫しています。数値は、範囲0 <= sortorder <2^31の整数でなければなりません。 +

+
+
+
+
+

+An AddressBook with a lower order is to be displayed before a AddressBook with a higher order in any list of AddressBooks in the client's UI. AddressBooks with equal order should be sorted in alphabetical order by name. The sorting should take into account locale-specific character order convention. +

+
+
+

+低次のアドレスブックは、クライアントのUIのアドレスブックのリストに高次のアドレスブックの前に表示されます。等しい注文のアドレスブックは、名前でアルファベット順にソートする必要があります。ソートは、ロケール固有のキャラクター順序条約を考慮に入れる必要があります。 +

+
+
+
+
+

+*isDefault*: Boolean (server-set) +

+
+
+

+*isdefault*：boolean（server-set） +

+
+
+
+
+

+This SHOULD be true for exactly one AddressBook in any account and MUST NOT be true for more than one AddressBook within an account. The default AddressBook should be used by clients whenever they need to choose an AddressBook for the user within this account and they do not have any other information on which to make a choice. For example, if the user creates a new contact card, the client may automatically set the card as belonging to the default AddressBook from the user's primary account. +

+
+
+

+これは、任意のアカウントの1つのアドレスブックに当てはまるはずであり、アカウント内の複数のアドレスブックに当てはまりません。デフォルトのアドレスブックは、このアカウント内のユーザーのアドレスブックを選択する必要がある場合はいつでもクライアントが使用する必要があり、選択するための他の情報がありません。たとえば、ユーザーが新しい連絡先カードを作成した場合、クライアントはユーザーのプライマリアカウントからデフォルトのアドレスブックに属するものとしてカードを自動的に設定できます。 +

+
+
+
+
+

+*isSubscribed*: Boolean +

+
+
+

+*Issubscribed*：boolean +

+
+
+
+
+

+True if the user has indicated they wish to see this AddressBook in their client. This SHOULD default to false for AddressBooks in shared accounts that the user has access to and true for any new AddressBooks created by the user themself. +

+
+
+

+ユーザーがクライアントにこのアドレスブックを見たいと思っていることを示している場合は、本当です。これは、ユーザーが作成した新しいアドレスブックにアクセスし、真実である共有アカウントのアドレス帳の場合はデフォルトである必要があります。 +

+
+
+
+
+

+If false, the AddressBook and its contents SHOULD only be displayed when the user explicitly requests it. The UI may offer to the user the option of subscribing to it. +

+
+
+

+falseの場合、アドレスブックとその内容は、ユーザーが明示的に要求した場合にのみ表示する必要があります。UIは、ユーザーにサブスクライブするオプションを提供する場合があります。 +

+
+
+
+
+

+*shareWith*: Id[AddressBookRights]|null (default: null) +

+
+
+

+*sharewith*：id [addressbookrights] | null（default：null） +

+
+
+
+
+

+A map of the Principal id (Section 2 of [RFC9670]) to rights for Principals this AddressBook is shared with. The Principal to which this AddressBook belongs MUST NOT be in this set. This is null if the AddressBook is not shared with anyone or if the server does not support [RFC9670]. The value may be modified only if the user has the "mayShare" right. The account id for the Principals may be found in the urn:ietf:params:jmap:principals:owner capability of the Account to which the AddressBook belongs. +

+
+
+

+プリンシパルの権利に対するプリンシパルID（[RFC9670]のセクション2）のマップは、このアドレスブックが共有されています。このアドレスブックが属する校長は、このセットに属してはなりません。これは、アドレスブックが誰とも共有されていない場合、またはサーバーが[RFC9670]をサポートしていない場合にヌルです。値は、ユーザーが「メイシャレ」を正しく持っている場合にのみ変更できます。プリンシパルのアカウントIDは、urn：ietf：params：jmap：principals：addersbookが属するアカウントの所有者能力に記載されている場合があります。 +

+
+
+
+
+

+*myRights*: AddressBookRights (server-set) +

+
+
+

+*MyRights*：AddressBookrights（サーバーセット） +

+
+
+
+
+

+The set of access rights the user has in relation to this AddressBook. +

+
+
+

+ユーザーがこのアドレスブックに関連して持っているアクセス権のセット。 +

+
+
+
+
+

+An *AddressBookRights* object has the following properties: +

+
+
+

+* addressbookrights *オブジェクトには次のプロパティがあります。 +

+
+
+
+
+

+*mayRead*: Boolean +

+
+
+

+*mayread*：boolean +

+
+
+
+
+

+The user may fetch the ContactCards in this AddressBook. +

+
+
+

+ユーザーは、このアドレスブックにコンタクトカードを取得できます。 +

+
+
+
+
+

+*mayWrite*: Boolean +

+
+
+

+*メイライト*：ブール +

+
+
+
+
+

+The user may create, modify, or destroy all ContactCards in this AddressBook, or move them to or from this AddressBook. +

+
+
+

+ユーザーは、このアドレスブックのすべてのコンタクトカードを作成、変更、または破壊するか、このアドレスブックとの間で移動する場合があります。 +

+
+
+
+
+

+*mayShare*: Boolean +

+
+
+

+*Mayshare*：Boolean +

+
+
+
+
+

+The user may modify the "shareWith" property for this AddressBook. +

+
+
+

+ユーザーは、このアドレスブックの「ShareWith」プロパティを変更できます。 +

+
+
+
+
+

+*mayDelete*: Boolean +

+
+
+

+*MayDelete*：boolean +

+
+
+
+
+

+The user may delete the AddressBook itself. +

+
+
+

+ユーザーは、アドレスブック自体を削除できます。 +

+
+
+
+
+
+2.1. AddressBook/get +
+
+
+
+2.1. アドレスbook/get +
+
+
+
+
+

+This is a standard "/get" method as described in Section 5.1 of [RFC8620]. The "ids" argument may be null to fetch all at once. +

+
+
+

+これは、[RFC8620]のセクション5.1で説明されている標準「/get」メソッドです。「IDS」引数は、一度にすべてを取得するためにnullになる場合があります。 +

+
+
+
+
+
+2.2. AddressBook/changes +
+
+
+
+2.2. アドレスブック/変更 +
+
+
+
+
+

+This is a standard "/changes" method as described in Section 5.2 of [RFC8620]. +

+
+
+

+これは、[RFC8620]のセクション5.2で説明されている標準の「/変更」メソッドです。 +

+
+
+
+
+
+2.3. AddressBook/set +
+
+
+
+2.3. アドレスブック/セット +
+
+
+
+
+

+This is a standard "/set" method as described in Section 5.3 of [RFC8620], but with the following additional request arguments: +

+
+
+

+これは、[RFC8620]のセクション5.3で説明されている標準の「/セット」メソッドですが、次の追加リクエスト引数があります。 +

+
+
+
+
+

+*onDestroyRemoveContents*: Boolean (default: false) +

+
+
+

+*OndestroyRemoveContents*：boolean（デフォルト：false） +

+
+
+
+
+

+If false, any attempt to destroy an AddressBook that still has a ContactCard in it will be rejected with an "addressBookHasContents" SetError. If true, any ContactCard that is in the AddressBook will be removed from it, and if such a ContactCard does not belong to any other AddressBook, it will be destroyed. +

+
+
+

+falseの場合、まだコンタクトカードが含まれているアドレスブックを破壊しようとする試みは、「アドレスbookhascontents」seterrorで拒否されます。真実の場合、アドレスブックにあるコンタクトカードはそこから削除され、そのようなコンタクトカードが他のアドレスブックに属していない場合、破壊されます。 +

+
+
+
+
+

+*onSuccessSetIsDefault*: Id|null +

+
+
+

+*onsuccessetisdefault*：id | null +

+
+
+
+
+

+If an id is given, and all creates, updates, and destroys (if any) succeed without error, the server will try to set this AddressBook as the default. (For references to AddressBook creations, this is equivalent to a creation-reference, so the id will be the creation id prefixed with a "#".) +

+
+
+

+IDが指定され、すべてがエラーなしですべての作成、更新、破壊が成功した場合、サーバーはこのアドレスブックをデフォルトとして設定しようとします。（アドレスブックの作成への参照については、これは作成の参照に相当するため、IDは「＃」が付いた作成IDになります。） +

+
+
+
+
+

+If the id is not found or if the change is not permitted by the server for policy reasons, it MUST be ignored and the current default AddressBook (if any) will remain as such. No error is returned to the client in this case. +

+
+
+

+IDが見つからない場合、またはポリシーの理由でサーバーによって変更が許可されていない場合、それは無視する必要があり、現在のデフォルトアドレスブック（もしあれば）はそのように残ります。この場合、クライアントにエラーは返されません。 +

+
+
+
+
+

+As per Section 5.3 of [RFC8620], if the default AddressBook is successfully changed, any changed objects MUST be reported in either the "created" or "updated" argument in the response as appropriate, with the server-set value included. +

+
+
+

+[RFC8620]のセクション5.3によると、デフォルトのアドレスブックが正常に変更された場合、変更されたオブジェクトは、サーバーセット値を含めて、必要に応じて、応答の「作成」または「更新」引数のいずれかで報告する必要があります。 +

+
+
+
+
+

+The "shareWith" property may only be set by users that have the "mayShare" right. When modifying the "shareWith" property, the user cannot give a right to a Principal if the Principal did not already have that right and the user making the change also does not have that right. Any attempt to do so MUST be rejected with a "forbidden" SetError. +

+
+
+

+「ShareWith」プロパティは、「Mayshare」が正しいユーザーによってのみ設定される場合があります。「ShareWith」プロパティを変更する場合、プリンシパルがまだその権利を持っていない場合、ユーザーは校長に権利を与えることはできません。そうする試みは、「禁じられた」セットナーで拒否されなければなりません。 +

+
+
+
+
+

+Users can subscribe or unsubscribe to an AddressBook by setting the "isSubscribed" property. The server MAY forbid users from subscribing to certain AddressBooks even though they have permission to see them, rejecting the update with a "forbidden" SetError. +

+
+
+

+ユーザーは、「ISSUBScribed」プロパティを設定することにより、アドレスブックを購読または登録解除できます。サーバーは、ユーザーが特定のアドレスブックに購読することを禁止する場合があります。 +

+
+
+
+
+

+The following extra SetError type is defined for "destroy": +

+
+
+

+次の追加セットエラータイプは、「破壊」用に定義されています。 +

+
+
+
+
+

+*addressBookHasContents*: +

+
+
+

+*addressbookhascontents*： +

+
+
+
+
+

+The AddressBook has at least one ContactCard assigned to it and the "onDestroyRemoveContents" argument was false. +

+
+
+

+アドレスブックには、少なくとも1つのコンタクトカードが割り当てられており、「ondestroyremovocontents」の引数は虚偽でした。 +

+
+
+
+
+
+3. ContactCards +
+
+
+
+3. コンタクトカード +
+
+
+
+
+

+A *ContactCard* object contains information about a person, company, or other entity, or represents a group of such entities. It is a JSContact Card object as defined in Section 2 of [RFC9553] with the following additional properties: +

+
+
+

+A * ContactCard *オブジェクトには、個人、会社、またはその他のエンティティに関する情報が含まれているか、そのようなエンティティのグループを表します。これは、[RFC9553]のセクション2で定義されているJScontactカードオブジェクトであり、次の追加プロパティがあります。 +

+
+
+
+
+

+*id*: Id (immutable; server-set) +

+
+
+

+*id*：id（inmutable; server-set） +

+
+
+
+
+

+The id of the ContactCard. The "id" property MAY be different to the ContactCard's "uid" property (as defined in Section 2.1.9 of [RFC9553]). However, there MUST NOT be more than one ContactCard with the same uid in an Account. +

+
+
+

+コンタクトカードのID。「ID」プロパティは、ContactCardの「UID」プロパティとは異なる場合があります（[RFC9553]のセクション2.1.9で定義されています）。ただし、アカウントに同じUIDを持つコンタクトカードが1つ以上ないはずです。 +

+
+
+
+
+

+*addressBookIds*: Id[Boolean] +

+
+
+

+*addressbookids*：id [boolean] +

+
+
+
+
+

+The set of AddressBook ids that this ContactCard belongs to. A card MUST belong to at least one AddressBook at all times (until it is destroyed). The set is represented as an object, with each key being an AddressBook id. The value for each key in the object MUST be true. +

+
+
+

+このコンタクトカードが属するアドレス帳IDのセット。カードは、常に少なくとも1つのアドレスブックに属している必要があります（破壊されるまで）。セットはオブジェクトとして表され、各キーはアドレス帳IDです。オブジェクト内の各キーの値は真でなければなりません。 +

+
+
+
+
+

+For any Media object in the card (see Section 2.6.4 of [RFC9553]), a new property is defined: +

+
+
+

+カード内のメディアオブジェクト（[RFC9553]のセクション2.6.4を参照）については、新しいプロパティが定義されています。 +

+
+
+
+
+

+*blobId*: Id +

+
+
+

+*Blobid*：id +

+
+
+
+
+

+An id for the Blob representing the binary contents of the resource. +

+
+
+

+リソースのバイナリコンテンツを表すBLOBのID。 +

+
+
+
+
+

+When returning ContactCards, any Media with a URI that uses the "data:" URL scheme [RFC2397] SHOULD return a "blobId" property and omit the "uri" property, as this lets clients load the (potentially large) image file only when needed and avoids the overhead of Base64 encoding. The "mediaType" property MUST also be set. Similarly, when creating or updating a ContactCard, clients MAY send a "blobId" instead of the "uri" property for a Media object. +

+
+
+

+コンタクトカードを返すとき、「データ：」を使用するURIを持つメディアは、「blobid」プロパティを返し、「uri」プロパティを省略します。Base64エンコーディングのオーバーヘッドが必要で回避されます。「mediatype」プロパティも設定する必要があります。同様に、ContactCardを作成または更新するとき、クライアントはメディアオブジェクトの「URI」プロパティの代わりに「ブロビッド」を送信する場合があります。 +

+
+
+
+
+

+A contact card with a "kind" property equal to "group" represents a group of contacts. Clients often present these separately from other contact cards. The "members" property, as defined in Section 2.1.6 of [RFC9553], contains a set of uids (as defined in Section 2.1.9 of [RFC9553]) for other contacts that are the members of this group. Clients should consider the group to contain any ContactCard with a matching uid from any account they have access to that has support for the urn:ietf:params:jmap:contacts capability. Any uid that cannot be found SHOULD be ignored but preserved. For example, suppose a user adds contacts from a shared address book to their private group, then temporarily loses access to this address book. The uids cannot be resolved, so the contacts will disappear from the group. However, if they are given permission to access the data again, the uids will be found and the contacts will reappear. +

+
+
+

+「グループ」に等しい「種類」プロパティを持つ連絡先カードは、連絡先のグループを表します。多くの場合、クライアントは他の連絡先とは別にこれらを提示します。[RFC9553]のセクション2.1.6で定義されている「メンバー」プロパティには、このグループのメンバーである他の連絡先のUIDS（[RFC9553]のセクション2.1.9で定義されている）のセットが含まれています。クライアントは、urn：ietf：params：jmap：contacts capabilityのサポートを持っているアカウントにアクセスできる任意のアカウントから一致するuidを持つ任意のコンタクトカードを含めることをグループに検討する必要があります。見つけることができないuidは無視する必要がありますが、保存されます。たとえば、ユーザーが共有アドレス帳から個人グループに連絡先を追加してから、このアドレス帳へのアクセスを一時的に失います。UIDを解決できないため、連絡先はグループから消えます。ただし、データに再度アクセスする許可が与えられた場合、UIDSが見つかり、連絡先が再表示されます。 +

+
+
+
+
+
+3.1. ContactCard/get +
+
+
+
+3.1. contactCard/get +
+
+
+
+
+

+This is a standard "/get" method as described in Section 5.1 of [RFC8620]. +

+
+
+

+これは、[RFC8620]のセクション5.1で説明されている標準「/get」メソッドです。 +

+
+
+
+
+
+3.2. ContactCard/changes +
+
+
+
+3.2. ContactCard/変更 +
+
+
+
+
+

+This is a standard "/changes" method as described in Section 5.2 of [RFC8620]. +

+
+
+

+これは、[RFC8620]のセクション5.2で説明されている標準の「/変更」メソッドです。 +

+
+
+
+
+
+3.3. ContactCard/query +
+
+
+
+3.3. 連絡先/クエリ +
+
+
+
+
+

+This is a standard "/query" method as described in Section 5.5 of [RFC8620]. +

+
+
+

+これは、[RFC8620]のセクション5.5で説明されている標準の「/クエリ」メソッドです。 +

+
+
+
+
+
+3.3.1. Filtering +
+
+
+
+3.3.1. フィルタリング +
+
+
+
+
+

+A *FilterCondition* object has the following properties, any of which may be omitted: +

+
+
+

+A * FilterCondition *オブジェクトには、次のプロパティがあり、そのいずれかが省略される場合があります。 +

+
+
+
+
+

+*inAddressBook*: Id +

+
+
+

+*inaddressbook*：id +

+
+
+
+
+

+An AddressBook id. A card must be in this address book to match the condition. +

+
+
+

+アドレス帳です。この条件に合わせて、このアドレス帳にカードが必要です。 +

+
+
+
+
+

+*uid*: String +

+
+
+

+*uid*：文字列 +

+
+
+
+
+

+A card must have this string exactly as its uid (as defined in Section 2.1.9 of [RFC9553]) to match. +

+
+
+

+カードには、[RFC9553]のセクション2.1.9で定義されているように）とまったく同じ文字列が必要です。 +

+
+
+
+
+

+*hasMember*: String +

+
+
+

+*Hasmember*：文字列 +

+
+
+
+
+

+A card must have a "members" property (as defined in Section 2.1.6 of [RFC9553]) that contains this string as one of the uids in the set to match. +

+
+
+

+カードには、[RFC9553]のセクション2.1.6で定義されているように、この文字列をセットのUIDの1つとして含む「メンバー」プロパティが必要です。 +

+
+
+
+
+

+*kind*: String +

+
+
+

+*種類*：文字列 +

+
+
+
+
+

+A card must have a "kind" property (as defined in Section 2.1.4 of [RFC9553]) that equals this string exactly to match. +

+
+
+

+カードには、[RFC9553]のセクション2.1.4で定義されているように、この文字列に正確に一致するように等しい「種類」プロパティが必要です。 +

+
+
+
+
+

+*createdBefore*: UTCDate +

+
+
+

+*createdbefore*：utcdate +

+
+
+
+
+

+The "created" date-time of the ContactCard (as defined in Section 2.1.3 of [RFC9553]) must be before this date-time to match the condition. +

+
+
+

+コンタクトカードの「作成された」日付時間（[RFC9553]のセクション2.1.3で定義されている）は、この日付の前に条件と一致する必要があります。 +

+
+
+
+
+

+*createdAfter*: UTCDate +

+
+
+

+*createdafter*：utcdate +

+
+
+
+
+

+The "created" date-time of the ContactCard (as defined in Section 2.1.3 of [RFC9553]) must be the same or after this date-time to match the condition. +

+
+
+

+コンタクトカードの「作成された」日付時間（[RFC9553]のセクション2.1.3で定義されている）は、条件と一致するためにこの日付時間と同じまたは後に必要です。 +

+
+
+
+
+

+*updatedBefore*: UTCDate +

+
+
+

+*前に更新*：utcdate +

+
+
+
+
+

+The "updated" date-time of the ContactCard (as defined in Section 2.1.10 of [RFC9553]) must be before this date-time to match the condition. +

+
+
+

+コンタクトカードの「更新された」日付時間（[RFC9553]のセクション2.1.10で定義されている）は、この日付の前に条件に一致する必要があります。 +

+
+
+
+
+

+*updatedAfter*: UTCDate +

+
+
+

+*Affter*を更新：utcdate +

+
+
+
+
+

+The "updated" date-time of the ContactCard (as defined in Section 2.1.10 of [RFC9553]) must be the same or after this date-time to match the condition. +

+
+
+

+コンタクトカードの「更新された」日付時間（[RFC9553]のセクション2.1.10で定義されている）は、条件と一致するためにこの日付時間と同じか、後に同じでなければなりません。 +

+
+
+
+
+

+*text*: String +

+
+
+

+*テキスト*：文字列 +

+
+
+
+
+

+A card matches this condition if the text matches with text in the card. +

+
+
+

+テキストがカード内のテキストと一致する場合、カードはこの状態と一致します。 +

+
+
+
+
+

+*name*: String +

+
+
+

+*名前*：文字列 +

+
+
+
+
+

+A card matches this condition if the value of any NameComponent in the "name" property or the "full" property in the "name" property of the card (as defined in Section 2.2.1.2 of [RFC9553]) matches the value. +

+
+
+

+カードの「名前」プロパティのnameComponentの値またはカードの「名前」プロパティ（[RFC9553]のセクション2.2.1.2で定義されている）の「完全な」プロパティの値が値に一致する場合、カードはこの条件に一致します。 +

+
+
+
+
+

+*name/given*: String +

+
+
+

+*名前/指定*：文字列 +

+
+
+
+
+

+A card matches this condition if the value of a NameComponent with kind "given" inside the "name" property of the card (as defined in Section 2.2.1.2 of [RFC9553]) matches the value. +

+
+
+

+カードの「名前」プロパティ内に「与えられた」種類（[RFC9553]のセクション2.2.1.2で定義されている）が値と一致する場合、カードはこの状態と一致します。 +

+
+
+
+
+

+*name/surname*: String +

+
+
+

+*名前/姓*：文字列 +

+
+
+
+
+

+A card matches this condition if the value of a NameComponent with kind "surname" inside the "name" property of the card (as defined in Section 2.2.1.2 of [RFC9553]) matches the value. +

+
+
+

+カードの「名前」プロパティ内の「姓」（[RFC9553]のセクション2.2.1.2で定義されている）が値と一致する場合、カードはこの状態と一致します。 +

+
+
+
+
+

+*name/surname2*: String +

+
+
+

+*name/surname2*：文字列 +

+
+
+
+
+

+A card matches this condition if the value of a NameComponent with kind "surname2" inside the "name" property of the card (as defined in Section 2.2.1.2 of [RFC9553]) matches the value. +

+
+
+

+カードの「surname2」の「surname2」がある場合（[rfc9553]セクション2.2.1.2で定義されている）、namecomponentの値が[rfc9553]のセクション2.2.1.2で定義されている）の場合、この状態と一致します。 +

+
+
+
+
+

+*nickname*: String +

+
+
+

+*ニックネーム*：文字列 +

+
+
+
+
+

+A card matches this condition if the "name" of any Nickname in the "nicknames" property of the card (as defined in Section 2.2.2 of [RFC9553]) matches the value. +

+
+
+

+カードの「ニックネーム」プロパティ（[RFC9553]のセクション2.2.2で定義）のニックネームの「名前」が値に一致する場合、カードはこの状態と一致します。 +

+
+
+
+
+

+*organization*: String +

+
+
+

+*組織*：文字列 +

+
+
+
+
+

+A card matches this condition if the "name" of any Organization in the "organizations" property of the card (as defined in Section 2.2.3 of [RFC9553]) matches the value. +

+
+
+

+カードの「組織」プロパティ（[RFC9553]のセクション2.2.3で定義）の組織の「名前」が値に一致する場合、カードはこの条件と一致します。 +

+
+
+
+
+

+*email*: String +

+
+
+

+*電子メール*：文字列 +

+
+
+
+
+

+A card matches this condition if the "address" or "label" of any EmailAddress in the "emails" property of the card (as defined in Section 2.3.1 of [RFC9553]) matches the value. +

+
+
+

+カードの「電子メール」プロパティ（[RFC9553]のセクション2.3.1で定義されている）の電子メールアドレスの「アドレス」または「ラベル」が値に一致する場合、カードはこの状態と一致します。 +

+
+
+
+
+

+*phone*: String +

+
+
+

+*電話*：文字列 +

+
+
+
+
+

+A card matches this condition if the "number" or "label" of any Phone in the "phones" property of the card (as defined in Section 2.3.3 of [RFC9553]) matches the value. +

+
+
+

+カードの「電話」プロパティ（[RFC9553]のセクション2.3.3で定義されている）の任意の電話の「番号」または「ラベル」が値に一致する場合、カードはこの状態と一致します。 +

+
+
+
+
+

+*onlineService*: String +

+
+
+

+*onlineservice*：string +

+
+
+
+
+

+A card matches this condition if the "service", "uri", "user", or "label" of any OnlineService in the "onlineServices" property of the card (as defined in Section 2.3.2 of [RFC9553]) matches the value. +

+
+
+

+カードの「サービス」、「uri」、「user」、または「onlineservices」プロパティの任意の任意の任意の任意の任意の条件（[rfc9553]のセクション2.3.2で定義）が一致する場合、カードはこの状態に一致します。価値。 +

+
+
+
+
+

+*address*: String +

+
+
+

+*アドレス*：文字列 +

+
+
+
+
+

+A card matches this condition if the value of any AddressComponent in the "addresses" property or the "full" property in the "addresses" property of the card (as defined in Section 2.5.1 of [RFC9553]) matches the value. +

+
+
+

+カードの「アドレス」プロパティ内のaddressComponentの値または「[RFC9553]のセクション2.5.1で定義されている」の「アドレス」プロパティの「アドレス」プロパティの値が値に一致する場合、カードはこの条件に一致します。 +

+
+
+
+
+

+*note*: String +

+
+
+

+*注*：文字列 +

+
+
+
+
+

+A card matches this condition if the "note" of any Note in the "notes" property of the card (as defined in Section 2.8.3 of [RFC9553]) matches the value. +

+
+
+

+カードの「ノート」プロパティ（[RFC9553]のセクション2.8.3で定義されている）が値に一致する場合、カードはこの状態と一致します。 +

+
+
+
+
+

+If zero properties are specified on the FilterCondition, the condition MUST always evaluate to true. If multiple properties are specified, ALL must apply for the condition to be true (it is equivalent to splitting the object into one-property conditions and making them all the child of an AND filter operator). +

+
+
+

+フィルターコンディションでゼロプロパティが指定されている場合、条件は常にtrueに評価する必要があります。複数のプロパティが指定されている場合、すべてが真であるようにすべてを適用する必要があります（オブジェクトを1つのプロパティ条件に分割し、それらをすべてのフィルター演算子の子にすることに相当します）。 +

+
+
+
+
+

+The exact semantics for matching String fields is deliberately not defined to allow for flexibility in indexing implementation, subject to the following: +

+
+
+

+文字列フィールドを一致させる正確なセマンティクスは、以下に対応するインデックス作成の実装の柔軟性を可能にするために意図的に定義されていません。 +

+
+
+
+
+

+* Text SHOULD be matched in a case-insensitive manner. +

+
+
+

+* テキストは、ケースに依存しない方法で一致する必要があります。 +

+
+
+
+
+

+* Text contained in either (but matched) single or double quotes SHOULD be treated as a phrase search. That is, a match is required for that exact sequence of words, excluding the surrounding quotation marks. Use \", \', and \\ to match a literal ", ', and \ respectively in a phrase. +

+
+
+

+* どちらか（ただし一致した）または二重引用符に含まれるテキストは、フレーズ検索として扱う必要があります。つまり、周囲の引用符を除く、その正確な一連の単語に一致する必要があります。\ "、\ '、および\\を使用して、文字通り"、'、および\をフレーズでそれぞれ一致させます。 +

+
+
+
+
+

+* Outside of a phrase, whitespace SHOULD be treated as dividing separate tokens that may be searched for separately in the contact, but MUST all be present for the contact to match the filter. +

+
+
+

+* フレーズの外では、ホワイトスペースは、接触で別々に検索される可能性のある別々のトークンとして扱われる必要がありますが、フィルターと一致するように接触するためにはすべて存在する必要があります。 +

+
+
+
+
+

+* Tokens MAY be matched on a whole-word basis using stemming (e.g., a text search for bus would match "buses", but not "business"). +

+
+
+

+* トークンは、ステムを使用して全単語ベースで一致する場合があります（たとえば、バスのテキスト検索は「バス」と一致しますが、「ビジネス」ではありません）。 +

+
+
+
+
+
+3.3.2. Sorting +
+
+
+
+3.3.2. ソート +
+
+
+
+
+

+The following values for the "property" field on the Comparator object MUST be supported for sorting: +

+
+
+

+コンパレータオブジェクトの「プロパティ」フィールドの次の値は、ソートのためにサポートする必要があります。 +

+
+
+
+
+

+* "created" - The "created" date on the ContactCard. +

+
+
+

+* 「作成」 - コンタクトカードの「作成された」日付。 +

+
+
+
+
+

+* "updated" - The "updated" date on the ContactCard. +

+
+
+

+* 「更新」 - 連絡先カードの「更新された」日付。 +

+
+
+
+
+

+The following values for the "property" field on the Comparator object SHOULD be supported for sorting: +

+
+
+

+コンパレータオブジェクトの「プロパティ」フィールドの次の値は、ソートのためにサポートする必要があります。 +

+
+
+
+
+

+* "name/given" - The value of the first NameComponent in the "name" property whose "kind" is "given". +

+
+
+

+* 「名前/与えられた」 - 「dign」プロパティの最初のnamecomponentの値は、「Dism」が与えられます。 +

+
+
+
+
+

+* "name/surname" - The value of the first NameComponent in the "name" property whose "kind" is "surname". +

+
+
+

+* 「name/surname」 - 「姓」が「姓」である「name」プロパティの最初のnamecomponentの値。 +

+
+
+
+
+

+* "name/surname2" - The value of the first NameComponent in the "name" property whose "kind" is "surname2". +

+
+
+

+* 「name/surname2」 - 「surname2」である「name」プロパティの最初のnamecomponentの値。 +

+
+
+
+
+
+3.4. ContactCard/queryChanges +
+
+
+
+3.4. ContactCard/QueryChanges +
+
+
+
+
+

+This is a standard "/queryChanges" method as described in Section 5.6 of [RFC8620]. +

+
+
+

+これは、[RFC8620]のセクション5.6で説明されている標準の「/QueryChanges」メソッドです。 +

+
+
+
+
+
+3.5. ContactCard/set +
+
+
+
+3.5. contactcard/set +
+
+
+
+
+

+This is a standard "/set" method as described in Section 5.3 of [RFC8620]. +

+
+
+

+これは、[RFC8620]のセクション5.3で説明されている標準の「/セット」メソッドです。 +

+
+
+
+
+

+To set a new photo, the file must first be uploaded using the upload mechanism as described in Section 6.1 of [RFC8620]. This will give the client a valid blobId, size, and type to use. The server MUST reject attempts to set a file that is not a recognised image type as the photo for a card. +

+
+
+

+新しい写真を設定するには、[RFC8620]のセクション6.1で説明されているように、最初にアップロードメカニズムを使用してファイルをアップロードする必要があります。これにより、クライアントに使用する有効なブロビッド、サイズ、タイプが得られます。サーバーは、カードの写真として認識されている画像タイプではないファイルを設定しようとする試みを拒否する必要があります。 +

+
+
+
+
+
+3.6. ContactCard/copy +
+
+
+
+3.6. 連絡先/コピー +
+
+
+
+
+

+This is a standard "/copy" method as described in Section 5.4 of [RFC8620]. +

+
+
+

+これは、[RFC8620]のセクション5.4で説明されている標準の「/コピー」メソッドです。 +

+
+
+
+
+
+4. Examples +
+
+
+
+4. 例 +
+
+
+
+
+

+For brevity, only the "methodCalls" property of the Request object and the "methodResponses" property of the Response object is shown in the following examples. +

+
+
+

+簡潔にするために、リクエストオブジェクトの「メソッドコール」プロパティと応答オブジェクトの「メソッドレスポンズ」プロパティのみを次の例に示します。 +

+
+
+
+
+
+4.1. Fetching Initial Data +
+
+
+
+4.1. 初期データを取得します +
+
+
+
+
+

+A user has authenticated and the client has fetched the JMAP Session object. It finds a single Account with the "urn:ietf:params:jmap:contacts" capability with id "a0x9" and wants to fetch all the address books and contacts. It might make the following request: +

+
+
+

+ユーザーが認証されており、クライアントはJMAPセッションオブジェクトを取得しました。「urn：ietf：params：jmap：contacts "capability with id" a0x9」を使用した単一のアカウントを見つけ、すべてのアドレス帳と連絡先を取得したいと考えています。次のリクエストを行う可能性があります。 +

+
+
+
+
+ 
+   [
+     ["AddressBook/get", {
+       "accountId": "a0x9"
+     }, "0"],
+     ["ContactCard/get", {
+       "accountId": "a0x9"
+     }, "1"]
+   ]
+
+
+
+
+
+

+Figure 1: "methodCalls" Property of a JMAP Request +

+
+
+

+図1：JMAP要求の「MethodCalls」プロパティ +

+
+
+
+
+

+The server might respond with something like: +

+
+
+

+サーバーは次のようなもので応答する場合があります。 +

+
+
+
+
+ 
+   [
+     ["AddressBook/get", {
+       "accountId": "a0x9",
+       "list": [{
+         "id": "062adcfa-105d-455c-bc60-6db68b69c3f3",
+         "name": "Personal",
+         "description": null,
+         "sortOrder": 0,
+         "isDefault": true,
+         "isSubscribed": true,
+         "shareWith": {
+           "3f1502e0-63fe-4335-9ff3-e739c188f5dd": {
+             "mayRead": true,
+             "mayWrite": false,
+             "mayShare": false,
+             "mayDelete": false
+           }
+         },
+         "myRights": {
+           "mayRead": true,
+           "mayWrite": true,
+           "mayShare": true,
+           "mayDelete": false
+         }
+       }, {
+         "id": "cd40089d-35f9-4fd7-980b-ba3a9f1d74fe",
+         "name": "Autosaved",
+         "description": null,
+         "sortOrder": 1,
+         "isDefault": false,
+         "isSubscribed": true,
+         "shareWith": null,
+         "myRights": {
+           "mayRead": true,
+           "mayWrite": true,
+           "mayShare": true,
+           "mayDelete": false
+         }
+       }],
+       "notFound": [],
+       "state": "~4144"
+     }, "0"],
+     ["ContactCard/get", {
+       "accountId": "a0x9",
+       "list": [{
+         "id": "3",
+         "addressBookIds": {
+           "062adcfa-105d-455c-bc60-6db68b69c3f3": true
+         },
+         "name": {
+           "components": [
+             { "kind": "given", "value": "Joe" },
+             { "kind": "surname", "value": "Bloggs" }
+           ],
+           "isOrdered": true
+         },
+         "emails": {
+           "0": {
+             "contexts": {
+               "private": true
+             },
+             "address": "joe.bloggs@example.com"
+           }
+         }
+       }],
+       "notFound": [],
+       "state": "ewarbckaqJ::112"
+     }, "1"]
+   ]
+
+
+
+
+
+

+Figure 2: "methodResponses" Property of a JMAP Response +

+
+
+

+図2：JMAP応答の「MethodSponses」プロパティ +

+
+
+
+
+
+4.2. Changing the Default Address Book +
+
+
+
+4.2. デフォルトのアドレス帳を変更します +
+
+
+
+
+

+The client tries to change the default address book from "Personal" to "Autosaved" (and makes no other change): +

+
+
+

+クライアントは、デフォルトのアドレス帳を「個人」から「オートセーブド」に変更しようとします（そして、他の変更はありません）： +

+
+
+
+
+ 
+   [
+     ["AddressBook/set", {
+       "accountId": "a0x9",
+       "onSuccessSetIsDefault": "cd40089d-35f9-4fd7-980b-ba3a9f1d74fe"
+     }, "0"]
+   ]
+
+
+
+
+
+

+Figure 3: "methodCalls" Property of a JMAP Request +

+
+
+

+図3：JMAP要求の「MethodCalls」プロパティ +

+
+
+
+
+

+The server allows the change, returning the following response: +

+
+
+

+サーバーは変更を許可し、次の応答を返します。 +

+
+
+
+
+ 
+   [
+     ["AddressBook/set", {
+       "accountId": "a0x9",
+       "updated": {
+         "cd40089d-35f9-4fd7-980b-ba3a9f1d74fe": {
+           "isDefault": true
+         },
+         "062adcfa-105d-455c-bc60-6db68b69c3f3": {
+           "isDefault": false
+         },
+         "oldState": "~4144",
+         "newState": "~4148"
+       }
+     }, "0"]
+   ]
+
+
+
+
+
+

+Figure 4: "methodResponses" Property of a JMAP Response +

+
+
+

+図4：JMAP応答の「MethodSponses」プロパティ +

+
+
+
+
+
+5. Internationalisation Considerations +
+
+
+
+5. 国際化の考慮事項 +
+
+
+
+
+

+Experience has shown that unrestricted use of Unicode can lead to problems such as inconsistent rendering, users reading text and interpreting it differently than intended, and unexpected results when copying text from one location to another. Servers MAY choose to mitigate this by restricting the set of characters allowed in otherwise unconstrained String fields. The FreeformClass, as documented in Section 4.3 of [RFC8264], might be a good starting point for this. +

+
+
+

+経験によると、Unicodeの無制限の使用は、一貫性のないレンダリング、ユーザーがテキストを読んで、意図したものとは異なる方法で解釈するなどの問題につながる可能性があり、ある場所から別の場所にテキストをコピーする際の予期しない結果が得られることが示されています。サーバーは、制約のない文字列フィールドで許可されている文字のセットを制限することにより、これを軽減することを選択できます。[RFC8264]のセクション4.3に記載されているフリーフォームクラスは、これの良い出発点かもしれません。 +

+
+
+
+
+

+Attempts to set a value containing code points outside of the permissible set can be handled in a few ways by the server. The server could choose to strip the forbidden characters or replace them with U+FFFD (the Unicode replacement character) and store the resulting string. This is likely to be appropriate for non-printable characters -- such as the "Control Codes" defined in Section 23.1 (https://www.unicode.org/versions/latest/core-spec/chapter-23/#G20365) of [UNICODE], excluding newline (U+000A), carriage return (U+000D), and tab (U+0009) -- that can end up in data accidentally due to copy-and-paste issues but are invisible to the end user. JMAP allows the server to transform data on create/update as long as any changed properties are returned to the client in the "/set" response so it knows what has changed, as per Section 5.3 of [RFC8620]. Alternatively, the server MAY just reject the create/update with an "invalidProperties" SetError. +

+
+
+

+許容セットの外側にコードポイントを含む値を設定する試みは、サーバーによっていくつかの方法で処理できます。サーバーは、禁止された文字を剥がすか、u+fffd（Unicode置換文字）に置き換えて、結果の文字列を保存することを選択できます。これは、セクション23.1（https://www.unicode.org/versions/latest/core-pec/chapter-23/#g20365）で定義されている「コントロールコード」など、印刷できない文字に適している可能性があります。[Unicode]、Newline（U+000a）、キャリッジリターン（U+000D）、およびタブ（U+0009）を除く - コピーアンドパスティの問題により誤ってデータになりますが、エンドユーザー。JMAPを使用すると、[RFC8620]のセクション5.3によると、変更されたプロパティが「/set」応答でクライアントに返される限り、サーバーは作成/更新のデータを変換できます。あるいは、サーバーは、「nivalidproperties」setErrorで作成/更新を拒否するだけです。 +

+
+
+
+
+
+6. Security Considerations +
+
+
+
+6. セキュリティに関する考慮事項 +
+
+
+
+
+

+All security considerations of JMAP [RFC8620] apply to this specification. Additional considerations specific to the data types and functionality introduced by this document are described in the following subsection. +

+
+
+

+JMAP [RFC8620]のすべてのセキュリティ上の考慮事項は、この仕様に適用されます。このドキュメントで導入されたデータ型と機能に固有の追加の考慮事項については、以下のサブセクションで説明します。 +

+
+
+
+
+

+Contacts consist almost entirely of private, personally identifiable information, and represent the social connections of users. Privacy leaks can have real world consequences, and contact servers and clients MUST be mindful of the need to keep all data secure. +

+
+
+

+連絡先は、ほぼ完全にプライベートで個人的に識別可能な情報から構成され、ユーザーの社会的つながりを表しています。プライバシーリークは現実世界の結果をもたらす可能性があり、連絡先サーバーとクライアントは、すべてのデータを安全に保つ必要性に留意する必要があります。 +

+
+
+
+
+

+Servers MUST enforce the Access Control Lists (ACLs) set on address books to ensure only authorised data is shared. +

+
+
+

+サーバーは、アドレス帳に設定されたアクセス制御リスト（ACLS）を実施して、認定データのみが共有されるようにする必要があります。 +

+
+
+
+
+
+7. IANA Considerations +
+
+
+
+7. IANAの考慮事項 +
+
+
+
+
+
+7.1. JMAP Capability Registration for "contacts" +
+
+
+
+7.1. 「連絡先」のJMAP機能登録 +
+
+
+
+
+

+IANA has registered "contacts" in the "JMAP Capabilities" registry as follows: +

+
+
+

+IANAは、次のように「JMAP機能」レジストリに「連絡先」を登録しています。 +

+
+
+
+
+

+Capability Name: +

+
+
+

+機能名： +

+
+
+
+
+

+urn:ietf:params:jmap:contacts +

+
+
+

+urn：ietf：params：jmap：連絡先 +

+
+
+
+
+

+Intended Use: +

+
+
+

+使用目的： +

+
+
+
+
+

+common +

+
+
+

+一般 +

+
+
+
+
+

+Change Controller: +

+
+
+

+Change Controller： +

+
+
+
+
+

+IETF +

+
+
+

+IETF +

+
+
+
+
+

+Security and Privacy Considerations: +

+
+
+

+セキュリティとプライバシーの考慮事項： +

+
+
+
+
+

+this document, Section 6 +

+
+
+

+このドキュメント、セクション6 +

+
+
+
+
+

+Reference: +

+
+
+

+参照： +

+
+
+
+
+

+this document +

+
+
+

+このドキュメント +

+
+
+
+
+
+7.2. JMAP Data Type Registration for "AddressBook" +
+
+
+
+7.2. JMAPデータ型「アドレスブック」の登録 +
+
+
+
+
+

+IANA has registered "AddressBook" in the "JMAP Data Types" registry as follows: +

+
+
+

+IANAは、次のように「JMAPデータ型」レジストリに「アドレスブック」を登録しています。 +

+
+
+
+
+

+Type Name: +

+
+
+

+タイプ名： +

+
+
+
+
+

+AddressBook +

+
+
+

+アドレスブック +

+
+
+
+
+

+Can Reference Blobs: +

+
+
+

+塊を参照できます： +

+
+
+
+
+

+No +

+
+
+

+いいえ +

+
+
+
+
+

+Can Use for State Change: +

+
+
+

+状態の変更に使用できます： +

+
+
+
+
+

+Yes +

+
+
+

+はい +

+
+
+
+
+

+Capability: +

+
+
+

+能力： +

+
+
+
+
+

+urn:ietf:params:jmap:contacts +

+
+
+

+urn：ietf：params：jmap：連絡先 +

+
+
+
+
+

+Reference: +

+
+
+

+参照： +

+
+
+
+
+

+this document +

+
+
+

+このドキュメント +

+
+
+
+
+
+7.3. JMAP Data Type Registration for "ContactCard" +
+
+
+
+7.3. JMAPデータ型「ContactCard」の登録 +
+
+
+
+
+

+IANA has registered "ContactCard" in the "JMAP Data Types" registry as follows: +

+
+
+

+IANAは、次のように「JMAPデータ型」レジストリに「ContactCard」を登録しています。 +

+
+
+
+
+

+Type Name: +

+
+
+

+タイプ名： +

+
+
+
+
+

+ContactCard +

+
+
+

+ContactCard +

+
+
+
+
+

+Can Reference Blobs: +

+
+
+

+塊を参照できます： +

+
+
+
+
+

+Yes +

+
+
+

+はい +

+
+
+
+
+

+Can Use for State Change: +

+
+
+

+状態の変更に使用できます： +

+
+
+
+
+

+Yes +

+
+
+

+はい +

+
+
+
+
+

+Capability: +

+
+
+

+能力： +

+
+
+
+
+

+urn:ietf:params:jmap:contacts +

+
+
+

+urn：ietf：params：jmap：連絡先 +

+
+
+
+
+

+Reference: +

+
+
+

+参照： +

+
+
+
+
+

+this document +

+
+
+

+このドキュメント +

+
+
+
+
+
+7.4. JMAP Error Codes Registry +
+
+
+
+7.4. JMAPエラーコードレジストリ +
+
+
+
+
+

+The following subsection has registered a new error code in the "JMAP Error Codes" registry, as defined in Section 9 of [RFC8620]. +

+
+
+

+次のサブセクションは、[RFC8620]のセクション9で定義されているように、「JMAPエラーコード」レジストリに新しいエラーコードを登録しています。 +

+
+
+
+
+
+7.4.1. addressBookHasContents +
+
+
+
+7.4.1. アドレスbookhascontents +
+
+
+
+
+

+JMAP Error Code: +

+
+
+

+JMAPエラーコード： +

+
+
+
+
+

+addressBookHasContents +

+
+
+

+アドレスbookhascontents +

+
+
+
+
+

+Intended Use: +

+
+
+

+使用目的： +

+
+
+
+
+

+common +

+
+
+

+一般 +

+
+
+
+
+

+Change Controller: +

+
+
+

+Change Controller： +

+
+
+
+
+

+IETF +

+
+
+

+IETF +

+
+
+
+
+

+Description: +

+
+
+

+説明： +

+
+
+
+
+

+The AddressBook has at least one ContactCard assigned to it, and the "onDestroyRemoveContents" argument was false. +

+
+
+

+アドレスブックには、少なくとも1つのコンタクトカードが割り当てられており、「destroyremovocontents」の引数は虚偽でした。 +

+
+
+
+
+

+Reference: +

+
+
+

+参照： +

+
+
+
+
+

+This document, Section 2.3 +

+
+
+

+このドキュメント、セクション2.3 +

+
+
+
+
+
+7.5. JSContact Property Registrations +
+
+
+
+7.5. jScontactプロパティ登録 +
+
+
+
+
+

+IANA has registered the following additional properties in the "JSContact Properties" registry, as defined in Section 3 of [RFC9553]. +

+
+
+

+IANAは、[RFC9553]のセクション3で定義されているように、「JScontactプロパティ」レジストリに次の追加プロパティを登録しています。 +

+
+
+
+
+
+7.5.1. id +
+
+
+
+7.5.1. id +
+
+
+
+
+

+Property Name: +

+
+
+

+プロパティ名： +

+
+
+
+
+

+id +

+
+
+

+id +

+
+
+
+
+

+Property Type: +

+
+
+

+プロパティタイプ： +

+
+
+
+
+

+not applicable +

+
+
+

+適用できない +

+
+
+
+
+

+Property Context: +

+
+
+

+プロパティコンテキスト： +

+
+
+
+
+

+Card +

+
+
+

+カード +

+
+
+
+
+

+Intended Usage: +

+
+
+

+意図された使用法： +

+
+
+
+
+

+reserved +

+
+
+

+予約済み +

+
+
+
+
+

+Since Version: +

+
+
+

+バージョン以来： +

+
+
+
+
+

+1.0 +

+
+
+

+1.0 +

+
+
+
+
+

+Change Controller: +

+
+
+

+Change Controller： +

+
+
+
+
+

+IETF +

+
+
+

+IETF +

+
+
+
+
+

+Reference: +

+
+
+

+参照： +

+
+
+
+
+

+this document +

+
+
+

+このドキュメント +

+
+
+
+
+
+7.5.2. addressBookIds +
+
+
+
+7.5.2. addressbookids +
+
+
+
+
+

+Property Name: +

+
+
+

+プロパティ名： +

+
+
+
+
+

+addressBookIds +

+
+
+

+addressbookids +

+
+
+
+
+

+Property Type: +

+
+
+

+プロパティタイプ： +

+
+
+
+
+

+not applicable +

+
+
+

+適用できない +

+
+
+
+
+

+Property Context: +

+
+
+

+プロパティコンテキスト： +

+
+
+
+
+

+Card +

+
+
+

+カード +

+
+
+
+
+

+Intended Usage: +

+
+
+

+意図された使用法： +

+
+
+
+
+

+reserved +

+
+
+

+予約済み +

+
+
+
+
+

+Since Version: +

+
+
+

+バージョン以来： +

+
+
+
+
+

+1.0 +

+
+
+

+1.0 +

+
+
+
+
+

+Change Controller: +

+
+
+

+Change Controller： +

+
+
+
+
+

+IETF +

+
+
+

+IETF +

+
+
+
+
+

+Reference: +

+
+
+

+参照： +

+
+
+
+
+

+this document +

+
+
+

+このドキュメント +

+
+
+
+
+
+7.5.3. blobId +
+
+
+
+7.5.3. ブロビッド +
+
+
+
+
+

+Property Name: +

+
+
+

+プロパティ名： +

+
+
+
+
+

+blobId +

+
+
+

+ブロビッド +

+
+
+
+
+

+Property Type: +

+
+
+

+プロパティタイプ： +

+
+
+
+
+

+not applicable +

+
+
+

+適用できない +

+
+
+
+
+

+Property Context: +

+
+
+

+プロパティコンテキスト： +

+
+
+
+
+

+Media +

+
+
+

+メディア +

+
+
+
+
+

+Intended Usage: +

+
+
+

+意図された使用法： +

+
+
+
+
+

+reserved +

+
+
+

+予約済み +

+
+
+
+
+

+Since Version: +

+
+
+

+バージョン以来： +

+
+
+
+
+

+1.0 +

+
+
+

+1.0 +

+
+
+
+
+

+Change Controller: +

+
+
+

+Change Controller： +

+
+
+
+
+

+IETF +

+
+
+

+IETF +

+
+
+
+
+

+Reference: +

+
+
+

+参照： +

+
+
+
+
+

+this document +

+
+
+

+このドキュメント +

+
+
+
+
+
+8. References +
+
+
+
+8. 参考文献 +
+
+
+
+
+
+8.1. Normative References +
+
+
+
+8.1. 引用文献 +
+
+
+
+
+ 
+   [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>.
+
+
+
+
+
+ 
+   [RFC2397]  Masinter, L., "The "data" URL scheme", RFC 2397,
+              DOI 10.17487/RFC2397, August 1998,
+              <https://www.rfc-editor.org/info/rfc2397>.
+
+
+
+
+
+ 
+   [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>.
+
+
+
+
+
+ 
+   [RFC8620]  Jenkins, N. and C. Newman, "The JSON Meta Application
+              Protocol (JMAP)", RFC 8620, DOI 10.17487/RFC8620, July
+              2019, <https://www.rfc-editor.org/info/rfc8620>.
+
+
+
+
+
+ 
+   [RFC9553]  Stepanek, R. and M. Loffredo, "JSContact: A JSON
+              Representation of Contact Data", RFC 9553,
+              DOI 10.17487/RFC9553, May 2024,
+              <https://www.rfc-editor.org/info/rfc9553>.
+
+
+
+
+
+ 
+   [RFC9670]  Jenkins, N., Ed., "JSON Meta Application Protocol (JMAP)
+              Sharing", RFC 9670, DOI 10.17487/RFC9670, November 2024,
+              <https://www.rfc-editor.org/info/rfc9670>.
+
+
+
+
+
+
+8.2. Informative References +
+
+
+
+8.2. 参考引用 +
+
+
+
+
+ 
+   [RFC8264]  Saint-Andre, P. and M. Blanchet, "PRECIS Framework:
+              Preparation, Enforcement, and Comparison of
+              Internationalized Strings in Application Protocols",
+              RFC 8264, DOI 10.17487/RFC8264, October 2017,
+              <https://www.rfc-editor.org/info/rfc8264>.
+
+
+
+
+
+ 
+   [UNICODE]  The Unicode Consortium, "The Unicode Standard",
+              <https://www.unicode.org/versions/latest/>.
+
+
+
+
+
+
+Author's Address +
+
+
+
+著者の連絡先 +
+
+
+
+
+ 
+   Neil Jenkins (editor)
+   Fastmail
+   PO Box 234, Collins St West
+   Melbourne  VIC 8007
+   Australia
+   Email: neilj@fastmailteam.com
+   URI:   https://www.fastmail.com
+
+
+
+
+ + + diff --git a/html/rfc9639.html b/html/rfc9639.html new file mode 100644 index 000000000..444de7287 --- /dev/null +++ b/html/rfc9639.html @@ -0,0 +1,8575 @@ + + + + + + RFC 9639 - Free Lossless Audio Codec (FLAC) 日本語訳 + + + + + + + + + + + + +
+
+ + + +
+
+
+ + +
+
+
+ 
+Internet Engineering Task Force (IETF)                M.Q.C. van Beurden
+Request for Comments: 9639                                              
+Category: Standards Track                                      A. Weaver
+ISSN: 2070-1721                                            December 2024
+
+
+
+
+
+
+Free Lossless Audio Codec (FLAC) +
+
+
+
+無料のロスレスオーディオコーデック（FLAC） +
+
+
+
+
+
+Abstract +
+
+
+
+概要 +
+
+
+
+
+

+This document defines the Free Lossless Audio Codec (FLAC) format and its streamable subset. FLAC is designed to reduce the amount of computer storage space needed to store digital audio signals. It does this losslessly, i.e., it does so without losing information. FLAC is free in the sense that its specification is open and its reference implementation is open source. Compared to other lossless audio coding formats, FLAC is a format with low complexity and can be encoded and decoded with little computing resources. Decoding of FLAC has been implemented independently for many different platforms, and both encoding and decoding can be implemented without needing floating-point arithmetic. +

+
+
+

+このドキュメントでは、無料のロスレスオーディオコーデック（FLAC）形式とそのストリーミング可能なサブセットを定義します。FLACは、デジタルオーディオ信号の保存に必要なコンピューターストレージスペースの量を減らすように設計されています。これは損失がなく、つまり、情報を失うことなくそうします。FLACは、その仕様が開かれており、参照実装がオープンソースであるという意味で無料です。他のロスレスオーディオコーディング形式と比較して、FLACは複雑さが低い形式であり、コンピューティングリソースがほとんどないエンコードおよびデコードできます。FLACのデコードは、多くの異なるプラットフォームに対して独立して実装されており、フローティングポイント算術を必要とせずにエンコードとデコードの両方を実装できます。 +

+
+
+
+
+
+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/rfc9639. +

+
+
+

+このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9639で取得できます。 +

+
+
+
+
+
+Copyright Notice +
+
+
+
+著作権表示 +
+
+
+
+
+

+Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. +

+
+
+

+著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。 +

+
+
+
+
+

+This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. +

+
+
+

+このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。 +

+
+
+
+
+
+Table of Contents +
+
+
+
+目次 +
+
+
+
+
+ 
+   1.  Introduction
+   2.  Notation and Conventions
+   3.  Definitions
+   4.  Conceptual Overview
+     4.1.  Blocking
+     4.2.  Interchannel Decorrelation
+     4.3.  Prediction
+     4.4.  Residual Coding
+   5.  Format Principles
+   6.  Format Layout Overview
+   7.  Streamable Subset
+   8.  File-Level Metadata
+     8.1.  Metadata Block Header
+     8.2.  Streaminfo
+     8.3.  Padding
+     8.4.  Application
+     8.5.  Seek Table
+       8.5.1.  Seek Point
+     8.6.  Vorbis Comment
+       8.6.1.  Standard Field Names
+       8.6.2.  Channel Mask
+     8.7.  Cuesheet
+       8.7.1.  Cuesheet Track
+     8.8.  Picture
+   9.  Frame Structure
+     9.1.  Frame Header
+       9.1.1.  Block Size Bits
+       9.1.2.  Sample Rate Bits
+       9.1.3.  Channels Bits
+       9.1.4.  Bit Depth Bits
+       9.1.5.  Coded Number
+       9.1.6.  Uncommon Block Size
+       9.1.7.  Uncommon Sample Rate
+       9.1.8.  Frame Header CRC
+     9.2.  Subframes
+       9.2.1.  Subframe Header
+       9.2.2.  Wasted Bits per Sample
+       9.2.3.  Constant Subframe
+       9.2.4.  Verbatim Subframe
+       9.2.5.  Fixed Predictor Subframe
+       9.2.6.  Linear Predictor Subframe
+       9.2.7.  Coded Residual
+     9.3.  Frame Footer
+   10. Container Mappings
+     10.1.  Ogg Mapping
+     10.2.  Matroska Mapping
+     10.3.  ISO Base Media File Format (MP4) Mapping
+   11. Security Considerations
+   12. IANA Considerations
+     12.1.  Media Type Registration
+     12.2.  FLAC Application Metadata Block IDs Registry
+   13. References
+     13.1.  Normative References
+     13.2.  Informative References
+   Appendix A.  Numerical Considerations
+     A.1.  Determining the Necessary Data Type Size
+     A.2.  Stereo Decorrelation
+     A.3.  Prediction
+     A.4.  Residual
+     A.5.  Rice Coding
+   Appendix B.  Past Format Changes
+     B.1.  Addition of Blocking Strategy Bit
+     B.2.  Restriction of Encoded Residual Samples
+     B.3.  Addition of 5-Bit Rice Parameters
+     B.4.  Restriction of LPC Shift to Non-negative Values
+   Appendix C.  Interoperability Considerations
+     C.1.  Features outside of the Streamable Subset
+     C.2.  Variable Block Size
+     C.3.  5-Bit Rice Parameters
+     C.4.  Rice Escape Code
+     C.5.  Uncommon Block Size
+     C.6.  Uncommon Bit Depth
+     C.7.  Multi-Channel Audio and Uncommon Sample Rates
+     C.8.  Changing Audio Properties Mid-Stream
+   Appendix D.  Examples
+     D.1.  Decoding Example 1
+       D.1.1.  Example File 1 in Hexadecimal Representation
+       D.1.2.  Example File 1 in Binary Representation
+       D.1.3.  Signature and Streaminfo
+       D.1.4.  Audio Frames
+     D.2.  Decoding Example 2
+       D.2.1.  Example File 2 in Hexadecimal Representation
+       D.2.2.  Example File 2 in Binary Representation (Only Audio
+               Frames)
+       D.2.3.  Streaminfo Metadata Block
+       D.2.4.  Seek Table
+       D.2.5.  Vorbis Comment
+       D.2.6.  Padding
+       D.2.7.  First Audio Frame
+       D.2.8.  Second Audio Frame
+       D.2.9.  MD5 Checksum Verification
+     D.3.  Decoding Example 3
+       D.3.1.  Example File 3 in Hexadecimal Representation
+       D.3.2.  Example File 3 in Binary Representation (Only Audio
+               Frame)
+       D.3.3.  Streaminfo Metadata Block
+       D.3.4.  Audio Frame
+   Acknowledgments
+   Authors' Addresses
+
+
+
+
+
+
+1. Introduction +
+
+
+
+1. はじめに +
+
+
+
+
+

+This document defines the Free Lossless Audio Codec (FLAC) format and its streamable subset. FLAC files and streams can code for pulse-code modulated (PCM) audio with 1 to 8 channels, sample rates from 1 to 1048575 hertz, and bit depths from 4 to 32 bits. Most tools for coding to and decoding from the FLAC format have been optimized for CD-audio, which is PCM audio with 2 channels, a sample rate of 44.1 kHz, and a bit depth of 16 bits. +

+
+
+

+このドキュメントでは、無料のロスレスオーディオコーデック（FLAC）形式とそのストリーミング可能なサブセットを定義します。FLACファイルとストリームは、1〜8チャンネル、1〜1048575 Hertz、および4〜32ビットのビット深度を備えたパルスコード変調（PCM）オーディオをコーディングできます。FLAC形式のコーディングとデコードのためのほとんどのツールは、2つのチャネル、44.1 kHzのサンプルレート、および16ビットの少し深さを備えたPCMオーディオであるCD-Audio向けに最適化されています。 +

+
+
+
+
+

+FLAC is able to achieve lossless compression because samples in audio signals tend to be highly correlated with their close neighbors. In contrast with general-purpose compressors, which often use dictionaries, do run-length coding, or exploit long-term repetition, FLAC removes redundancy solely in the very short term, looking back at 32 samples at most. +

+
+
+

+FLACは、オーディオ信号のサンプルが近隣の隣人と高度に相関する傾向があるため、ロスレス圧縮を実現できます。しばしば辞書を使用したり、走行長のコーディングをしたり、長期的な繰り返しを活用したりする汎用コンプレッサーとは対照的に、FLACは非常に短期的にのみ冗長性を除去し、せいぜい32のサンプルを振り返ります。 +

+
+
+
+
+

+The coding methods provided by the FLAC format work best on PCM audio signals with samples that have a signed representation and are centered around zero. Audio signals in which samples have an unsigned representation must be transformed to a signed representation as described in this document in order to achieve reasonable compression. The FLAC format is not suited for compressing audio that is not PCM. +

+
+
+

+FLAC形式によって提供されるコーディング方法は、署名された表現があり、ゼロを中心とするサンプルを使用して、PCMオーディオ信号で最適に機能します。合理的な圧縮を実現するために、このドキュメントで説明されているように、サンプルが署名されていない表現を持つオーディオ信号を署名した表現に変換する必要があります。FLAC形式は、PCMではないオーディオを圧縮するのに適していません。 +

+
+
+
+
+
+2. Notation and Conventions +
+
+
+
+2. 表記と慣習 +
+
+
+
+
+

+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. +

+
+
+

+「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。 +

+
+
+
+
+

+Values expressed as u(n) represent an unsigned big-endian integer using n bits. Values expressed as s(n) represent a signed big-endian integer using n bits, signed two's complement. Where necessary, n is expressed as an equation using * (multiplication), / (division), + (addition), or - (subtraction). An inclusive range of the number of bits expressed is represented with an ellipsis, such as u(m...n). +

+
+
+

+u（n）として表される値は、nビットを使用して署名されていないビッグエンディアン整数を表します。s（n）として表される値は、nビットを使用して署名されたビッグエンディアンの整数を表し、署名された2の補数を表します。必要に応じて、nは *（乗算）、 /（分割）、 +（追加）、または - （減算）を使用した方程式として表されます。発現するビット数の包括的な範囲は、u（m ... n）などの楕円で表されます。 +

+
+
+
+
+

+All shifts mentioned in this document are arithmetic shifts. +

+
+
+

+このドキュメントに記載されているすべてのシフトは、算術シフトです。 +

+
+
+
+
+

+While the FLAC format can store digital audio as well as other digital signals, this document uses terminology specific to digital audio. The use of more generic terminology was deemed less clear, so a reader interested in non-audio use of the FLAC format is expected to make the translation from audio-specific terms to more generic terminology. +

+
+
+

+FLAC形式はデジタルオーディオと他のデジタル信号を保存できますが、このドキュメントではデジタルオーディオに固有の用語を使用します。より一般的な用語の使用はそれほど明確ではないと見なされたため、FLAC形式の非オーディオ使用に関心のある読者は、オーディオ固有の用語からより一般的な用語への翻訳を行うことが期待されています。 +

+
+
+
+
+
+3. Definitions +
+
+
+
+3. 定義 +
+
+
+
+
+

+*Lossless compression*: +

+
+
+

+*ロスレス圧縮*： +

+
+
+
+
+

+Reducing the amount of computer storage space needed to store data without needing to remove or irreversibly alter any of this data in doing so. In other words, decompressing losslessly compressed information returns exactly the original data. +

+
+
+

+このデータを削除または不可逆的に変更する必要なく、データを保存するために必要なコンピューターストレージスペースの量を減らす。言い換えれば、損失のない圧縮情報を減圧すると、元のデータが正確に返されます。 +

+
+
+
+
+

+*Lossy compression*: +

+
+
+

+*損失のある圧縮*： +

+
+
+
+
+

+Like lossless compression, but instead removing, irreversibly altering, or only approximating information for the purpose of further reducing the amount of computer storage space needed. In other words, decompressing lossy compressed information returns an approximation of the original data. +

+
+
+

+ロスレス圧縮のように、代わりに、必要なコンピューターストレージスペースの量をさらに削減する目的で、情報を削除、不可逆的に変更、または近似のみに近似します。言い換えれば、損失のある圧縮情報を減圧すると、元のデータの近似が返されます。 +

+
+
+
+
+

+*Block*: +

+
+
+

+*ブロック*： +

+
+
+
+
+

+A (short) section of linear PCM audio with one or more channels. +

+
+
+

+1つ以上のチャネルを備えた線形PCMオーディオの（短い）セクション。 +

+
+
+
+
+

+*Subblock*: +

+
+
+

+*サブブロック*： +

+
+
+
+
+

+All samples within a corresponding block for one channel. One or more subblocks form a block, and all subblocks in a certain block contain the same number of samples. +

+
+
+

+1つのチャネルの対応するブロック内のすべてのサンプル。1つ以上のサブブロックがブロックを形成し、特定のブロック内のすべてのサブブロックには同じ数のサンプルが含まれています。 +

+
+
+
+
+

+*Frame*: +

+
+
+

+*フレーム*： +

+
+
+
+
+

+A frame header, one or more subframes, and a frame footer. It encodes the contents of a corresponding block. +

+
+
+

+フレームヘッダー、1つ以上のサブフレーム、およびフレームフッター。対応するブロックの内容をコードします。 +

+
+
+
+
+

+*Subframe*: +

+
+
+

+*サブフレーム*： +

+
+
+
+
+

+An encoded subblock. All subframes within a frame code for the same number of samples. When interchannel decorrelation is used, a subframe can correspond to either the (per-sample) average of two subblocks or the (per-sample) difference between two subblocks, instead of to a subblock directly; see Section 4.2. +

+
+
+

+エンコードされたサブブロック。同じ数のサンプルのフレームコード内のすべてのサブフレーム。インターチャネルの切り相関を使用すると、サブフレームは、サブブロックの2つのサブブロックの（サンプルごとの）平均（サンプルごと）の差に直接対応できます。セクション4.2を参照してください。 +

+
+
+
+
+

+*Interchannel samples*: +

+
+
+

+*インターチャネルサンプル*： +

+
+
+
+
+

+A sample count that applies to all channels. For example, one second of 44.1 kHz audio has 44100 interchannel samples, meaning each channel has that number of samples. +

+
+
+

+すべてのチャネルに適用されるサンプルカウント。たとえば、44.1 KHzオーディオの1秒には44100個のチャネルインターチャネルサンプルがあります。つまり、各チャネルにはその数のサンプルがあります。 +

+
+
+
+
+

+*Block size*: +

+
+
+

+*ブロックサイズ*： +

+
+
+
+
+

+The number of interchannel samples contained in a block or coded in a frame. +

+
+
+

+ブロックに含まれるか、フレームにコード化されたインターチャネルサンプルの数。 +

+
+
+
+
+

+*Bit depth* or *bits per sample*: +

+
+
+

+*サンプルごとにビット深さ*または*ビット*： +

+
+
+
+
+

+The number of bits used to contain each sample. This MUST be the same for all subblocks in a block but MAY be different for different subframes in a frame because of interchannel decorrelation. (See Section 4.2 for details on interchannel decorrelation.) +

+
+
+

+各サンプルを含むために使用されるビット数。これは、ブロック内のすべてのサブブロックで同じである必要がありますが、チャネル間の切り相関があるため、フレーム内の異なるサブフレームで異なる場合があります。（インターチャンネルの切り相関の詳細については、セクション4.2を参照してください。） +

+
+
+
+
+

+*Predictor*: +

+
+
+

+*予測因子*： +

+
+
+
+
+

+A model used to predict samples in an audio signal based on past samples. FLAC uses such predictors to remove redundancy in a signal in order to be able to compress it. +

+
+
+

+過去のサンプルに基づいてオーディオ信号のサンプルを予測するために使用されるモデル。FLACは、このような予測因子を使用して、信号の冗長性を削除して圧縮できるようにします。 +

+
+
+
+
+

+*Linear predictor*: +

+
+
+

+*線形予測因子*： +

+
+
+
+
+

+A predictor using linear prediction (see [LinearPrediction]). This is also called *linear predictive coding (LPC)*. With a linear predictor, each prediction is a linear combination of past samples (hence the name). A linear predictor has a causal discrete-time finite impulse response (see [FIR]). +

+
+
+

+線形予測を使用した予測因子（[線形予測]を参照）。これは、 *線形予測コーディング（LPC） *とも呼ばれます。線形予測因子を使用すると、各予測は過去のサンプルの線形結合です（したがって名前）。線形予測因子には、因果的な離散時間有限インパルス応答があります（[FIR]を参照）。 +

+
+
+
+
+

+*Fixed predictor*: +

+
+
+

+*予測因子を修正*： +

+
+
+
+
+

+A linear predictor in which the model parameters are the same across all FLAC files and thus do not need to be stored. +

+
+
+

+モデルパラメーターがすべてのFLACファイルで同じであるため、保存する必要はない線形予測因子。 +

+
+
+
+
+

+*Predictor order*: +

+
+
+

+*予測因子順序*： +

+
+
+
+
+

+The number of past samples that a predictor uses. For example, a 4th order predictor uses the 4 samples directly preceding a certain sample to predict it. In FLAC, samples used in a predictor are always consecutive and are always the samples directly before the sample that is being predicted. +

+
+
+

+予測子が使用する過去のサンプルの数。たとえば、4次予測子は、特定のサンプルの直前の4つのサンプルを使用して予測します。FLACでは、予測子で使用されるサンプルは常に連続しており、常に予測されているサンプルの直前のサンプルです。 +

+
+
+
+
+

+*Residual*: +

+
+
+

+*残差*： +

+
+
+
+
+

+The audio signal that remains after a predictor has been subtracted from a subblock. If the predictor has been able to remove redundancy from the signal, the samples of the remaining signal (the *residual samples*) will have, on average, a numerical value closer to zero than the original signal. +

+
+
+

+予測子がサブブロックから差し引かれた後に残るオーディオ信号。予測子が信号から冗長性を削除できた場合、残りの信号（ *残差サンプル *）のサンプルには、平均して、元の信号よりもゼロに近い数値があります。 +

+
+
+
+
+

+*Rice code*: +

+
+
+

+*稲法*： +

+
+
+
+
+

+A variable-length code (see [VarLengthCode]). It uses a short code for samples close to zero and a progressively longer code for samples further away from zero. This makes use of the observation that residual samples are often close to zero. +

+
+
+

+変数長コード（[varlengthcode]を参照）。ゼロに近いサンプルには短いコードを使用し、ゼロから遠く離れたサンプルに次第に長いコードを使用します。これにより、残留サンプルはしばしばゼロに近いという観察が利用されます。 +

+
+
+
+
+

+*Muxing*: +

+
+
+

+*マクシング*： +

+
+
+
+
+

+Short for multiplexing. Combining several streams or files into a single stream or file. In the context of this document, muxing specifically refers to embedding a FLAC stream in a container as described in Section 10. +

+
+
+

+多重化の略。いくつかのストリームまたはファイルを単一のストリームまたはファイルに結合します。このドキュメントのコンテキストでは、Muxingは、セクション10で説明されているように、コンテナにFLACストリームを埋め込むことを特に指します。 +

+
+
+
+
+
+4. Conceptual Overview +
+
+
+
+4. 概念的概要 +
+
+
+
+
+

+Similar to many other audio coders, a FLAC file is encoded following the steps below. To decode a FLAC file, these steps are performed in reverse order, i.e., from bottom to top. +

+
+
+

+他の多くのオーディオコーダーと同様に、FLACファイルは以下の手順に従ってエンコードされています。FLACファイルをデコードするには、これらの手順は逆の順序で、つまり下から上に実行されます。 +

+
+
+
+
+

+1. *Blocking* (see Section 4.1). The input is split up into many contiguous blocks. +

+
+
+

+1. *ブロック*（セクション4.1を参照）。入力は、多くの連続したブロックに分割されます。 +

+
+
+
+
+

+2. *Interchannel Decorrelation* (see Section 4.2). In the case of stereo streams, the FLAC format allows for transforming the left-right signal into a mid-side signal, a left-side signal, or a side-right signal to remove redundancy between channels. Choosing between any of these transformations is done independently for each block. +

+
+
+

+2. *交換相関関係*（セクション4.2を参照）。ステレオストリームの場合、FLAC形式では、左右信号をミッドサイド信号、左側信号、またはチャネル間の冗長性を除去する側面右信号に変換できます。これらの変換のいずれかを選択することは、各ブロックに対して個別に行われます。 +

+
+
+
+
+

+3. *Prediction* (see Section 4.3). To remove redundancy in a signal, a predictor is stored for each subblock or its transformation as formed in the previous step. A predictor consists of a simple mathematical description that can be used, as the name implies, to predict a certain sample from the samples that preceded it. As this prediction is rarely exact, the error of this prediction is passed on to the next stage. The predictor of each subblock is completely independent from other subblocks. Since the methods of prediction are known to both the encoder and decoder, only the parameters of the predictor need to be included in the compressed stream. If no usable predictor can be found for a certain subblock, the signal is stored uncompressed, and the next stage is skipped. +

+
+
+

+3. *予測*（セクション4.3を参照）。信号の冗長性を削除するために、前のステップで形成された各サブブロックまたはその変換に対して予測子が保存されます。予測因子は、名前が示すように、それに先行するサンプルから特定のサンプルを予測するために使用できる単純な数学的説明で構成されています。この予測はめったに正確ではないため、この予測の誤差は次の段階に渡されます。各サブブロックの予測因子は、他のサブブロックから完全に独立しています。予測の方法はエンコーダーとデコーダーの両方に知られているため、予測子のパラメーターのみを圧縮ストリームに含める必要があります。特定のサブブロックに対して使用可能な予測子が見つからない場合、信号は圧縮されていない保存され、次の段階がスキップされます。 +

+
+
+
+
+

+4. *Residual Coding* (see Section 4.4). As the predictor does not describe the signal exactly, the difference between the original signal and the predicted signal (called the error or residual signal) is coded losslessly. If the predictor is effective, the residual signal will require fewer bits per sample than the original signal. FLAC uses Rice coding, a subset of Golomb coding, with either 4-bit or 5-bit parameters to code the residual signal. +

+
+
+

+4. *残留コーディング*（セクション4.4を参照）。予測子は信号を正確に記述していないため、元の信号と予測信号（エラーまたは残差信号と呼ばれる）の違いは損失を及ぼさないほどコード化されます。予測子が有効な場合、残差信号は元の信号よりもサンプルあたりのビットが少なくなります。FLACは、残差信号をコーディングするために、4ビットまたは5ビットパラメーターを備えたGolombコーディングのサブセットであるRice Codingを使用します。 +

+
+
+
+
+

+In addition, FLAC specifies a metadata system (see Section 8) that allows arbitrary information about the stream to be included at the beginning of the stream. +

+
+
+

+さらに、FLACは、ストリームの開始時にストリームに関する任意の情報を含めるメタデータシステム（セクション8を参照）を指定します。 +

+
+
+
+
+
+4.1. Blocking +
+
+
+
+4.1. ブロッキング +
+
+
+
+
+

+The block size used for audio data has a direct effect on the compression ratio. If the block size is too small, the resulting large number of frames means that a disproportionate number of bytes will be spent on frame headers. If the block size is too large, the characteristics of the signal may vary so much that the encoder will be unable to find a good predictor. In order to simplify encoder/ decoder design, FLAC imposes a minimum block size of 16 samples, except for the last block, and a maximum block size of 65535 samples. The last block is allowed to be smaller than 16 samples to be able to match the length of the encoded audio without using padding. +

+
+
+

+オーディオデータに使用されるブロックサイズは、圧縮比に直接的な影響を及ぼします。ブロックサイズが小さすぎる場合、結果として生じる多くのフレームは、フレームヘッダーに不均衡な数のバイト数が使用されることを意味します。ブロックサイズが大きすぎると、信号の特性が大きく異なる場合があるため、エンコーダーは適切な予測因子を見つけることができません。エンコーダー/デコーダー設計を簡素化するために、FLACは、最後のブロックを除き、16のサンプルの最小ブロックサイズと65535サンプルの最大ブロックサイズを課します。最後のブロックは、パディングを使用せずにエンコードされたオーディオの長さを一致させるために、16枚未満のサンプルになります。 +

+
+
+
+
+

+While the block size does not have to be constant in a FLAC file, it is often difficult to find the optimal arrangement of block sizes for maximum compression. Because of this, a FLAC stream has explicitly either a constant or variable block size throughout and stores a block number instead of a sample number to slightly improve compression if a stream has a constant block size. +

+
+
+

+ブロックサイズはFLACファイルで一定である必要はありませんが、最大圧縮のためにブロックサイズの最適な配置を見つけることはしばしば困難です。このため、FLACストリームは、全体に一定または可変ブロックサイズを明示的に備えており、サンプル番号の代わりにブロック番号を保存して、ストリームに一定のブロックサイズがある場合は圧縮をわずかに改善します。 +

+
+
+
+
+
+4.2. Interchannel Decorrelation +
+
+
+
+4.2. チャンネル間の切り相関 +
+
+
+
+
+

+Channels are correlated in many audio files. The FLAC format can exploit this correlation in stereo files by coding an average of all samples in both subblocks (a mid channel) or the difference between all samples in both subblocks (a side channel) instead of directly coding subblocks into subframes. The following combinations are possible: +

+
+
+

+チャネルは多くのオーディオファイルで相関しています。FLAC形式は、サブブロックをサブフレームに直接コーディングする代わりに、両方のサブブロック（ミッドチャネル）のすべてのサンプルの平均または両方のサブブロック（サイドチャネル）のすべてのサブブロックの平均をコーディングすることにより、ステレオファイルのこの相関を活用できます。次の組み合わせが可能です。 +

+
+
+
+
+

+* *Independent*. All channels are coded independently. All non-stereo files MUST be encoded this way. +

+
+
+

+* *独立した*。すべてのチャネルは独立してコーディングされます。すべての非ステレオファイルはこの方法でエンコードする必要があります。 +

+
+
+
+
+

+* *Mid-side*. A left and right subblock are converted to mid and side subframes. To calculate a sample for a mid subframe, the corresponding left and right samples are summed, and the result is shifted right by 1 bit. To calculate a sample for a side subframe, the corresponding right sample is subtracted from the corresponding left sample. On decoding, all mid channel samples have to be shifted left by 1 bit. Also, if a side channel sample is odd, 1 has to be added to the corresponding mid channel sample after it has been shifted left by 1 bit. To reconstruct the left channel, the corresponding samples in the mid and side subframes are added and the result shifted right by 1 bit. For the right channel, the side channel has to be subtracted from the mid channel and the result shifted right by 1 bit. +

+
+
+

+* *ミッドサイド*。左右のサブブロックは、ミッドサブフレームとサイドサブフレームに変換されます。ミッドサブフレームのサンプルを計算するために、対応する左右のサンプルが合計され、結果は1ビットずつシフトします。サイドサブフレームのサンプルを計算するには、対応する右サンプルが対応する左サンプルから差し引かれます。デコードでは、すべてのミッドチャネルサンプルを1ビット左にシフトする必要があります。また、サイドチャネルサンプルが奇数の場合、1ビットの残りをシフトした後、対応するミッドチャネルサンプルに1を追加する必要があります。左チャネルを再構築するために、中央および側面のサブフレームの対応するサンプルが追加され、結果が1ビット右にシフトしました。右チャネルの場合、サイドチャネルをミッドチャネルから差し引く必要があり、結果は1ビット右にシフトしました。 +

+
+
+
+
+

+* *Left-side*. The left subblock is coded, and the left and right subblocks are used to code a side subframe. The side subframe is constructed in the same way as for mid-side. To decode, the right subblock is restored by subtracting the samples in the side subframe from the corresponding samples in the left subframe. +

+
+
+

+* *左側*。左サブブロックがコード化されており、左右のサブブロックを使用してサイドサブフレームをコーディングします。サイドサブフレームは、ミッドサイドと同じ方法で構築されます。デコードするには、右サブブロックが左サブフレームの対応するサンプルからサイドサブフレームのサンプルを差し引くことで復元されます。 +

+
+
+
+
+

+* *Side-right*. The left and right subblocks are used to code a side subframe, and the right subblock is coded. The side subframe is constructed in the same way as for mid-side. To decode, the left subblock is restored by adding the samples in the side subframe to the corresponding samples in the right subframe. +

+
+
+

+* *side-right*。左右のサブブロックは、サイドサブフレームのコーディングに使用され、右サブブロックがコーディングされています。サイドサブフレームは、ミッドサイドと同じ方法で構築されます。デコードするには、右サブフレームのサンプルを右サブフレームの対応するサンプルに追加することにより、左サブブロックが復元されます。 +

+
+
+
+
+

+The side channel needs one extra bit of bit depth, as the subtraction can produce sample values twice as large as the maximum possible in any given bit depth. The mid channel in mid-side stereo does not need one extra bit, as it is shifted right 1 bit. The right shift of the mid channel does not lead to lossy behavior because an odd sample in the mid subframe must always be accompanied by a corresponding odd sample in the side subframe, which means the lost least-significant bit can be restored by taking it from the sample in the side subframe. +

+
+
+

+サイドチャネルには、減算が任意のビット深度で可能な最大値の2倍のサンプル値を生成できるため、ビットの深さを1つ追加する必要があります。ミッドサイドステレオのミッドチャネルは、1ビットにシフトされているため、追加のビットは必要ありません。ミッドチャネルの正しいシフトは、ミッドサブフレームの奇数サンプルには常にサイドサブフレームに対応する奇数サンプルを添付する必要があるため、損失のある動作につながりません。サイドサブフレームのサンプル。 +

+
+
+
+
+
+4.3. Prediction +
+
+
+
+4.3. 予測 +
+
+
+
+
+

+The FLAC format has four methods for modeling the input signal: +

+
+
+

+FLAC形式には、入力信号をモデル化する4つの方法があります。 +

+
+
+
+
+

+1. *Verbatim*. Samples are stored directly, without any modeling. This method is used for inputs with little correlation. Since the raw signal is not actually passed through the residual coding stage (it is added to the stream "verbatim"), this method is different from using a zero-order fixed predictor. +

+
+
+

+1. *Verbatim*。サンプルは、モデリングなしで直接保存されます。この方法は、ほとんど相関関係がない入力に使用されます。生の信号は実際には残留コーディング段階を通過しないため（ストリーム「逐語」）、この方法はゼロオーダー固定予測子を使用することとは異なります。 +

+
+
+
+
+

+2. *Constant*. A single sample value is stored. This method is used whenever a signal is pure DC ("digital silence"), i.e., a constant value throughout. +

+
+
+

+2. *絶え間ない*。単一のサンプル値が保存されます。この方法は、信号が純粋なDC（「デジタルサイレンス」）、つまり全体の一定の値である場合はいつでも使用されます。 +

+
+
+
+
+

+3. *Fixed predictor*. Samples are predicted with one of five fixed (i.e., predefined) predictors, and the error of this prediction is processed by the residual coder. These fixed predictors are well suited for predicting simple waveforms. Since the predictors are fixed, no predictor coefficients are stored. From a mathematical point of view, the predictors work by extrapolating the signal from the previous samples. The number of previous samples used is equal to the predictor order. For more information, see Section 9.2.5. +

+
+
+

+3. *予測因子を修正*。サンプルは、5つの固定（つまり、事前定義された）予測因子のいずれかで予測され、この予測の誤差は残差コーダーによって処理されます。これらの固定予測因子は、単純な波形を予測するのに適しています。予測因子は固定されているため、予測係数は保存されません。数学的な観点から、予測因子は以前のサンプルから信号を外挿することにより機能します。以前のサンプルの数は、予測順に等しくなります。詳細については、セクション9.2.5を参照してください。 +

+
+
+
+
+

+4. *Linear predictor*. Samples are predicted using past samples and a set of predictor coefficients, and the error of this prediction is processed by the residual coder. Compared to a fixed predictor, using a generic linear predictor adds overhead as predictor coefficients need to be stored. Therefore, this method of prediction is best suited for predicting more complex waveforms, where the added overhead is offset by space savings in the residual coding stage resulting from more accurate prediction. A linear predictor in FLAC has two parameters besides the predictor coefficients and the predictor order: the number of bits with which each coefficient is stored (the coefficient precision) and a prediction right shift. A prediction is formed by taking the sum of multiplying each predictor coefficient with the corresponding past sample and dividing that sum by applying the specified right shift. For more information, see Section 9.2.6. +

+
+
+

+4. *線形予測因子*。サンプルは、過去のサンプルと一連の予測係数を使用して予測され、この予測の誤差は残差コーダーによって処理されます。固定予測子と比較して、一般的な線形予測因子を使用すると、予測係数を保存する必要があるためオーバーヘッドが追加されます。したがって、この予測の方法は、より正確な予測に起因する残留コーディング段階でのスペースの節約により、より複雑な波形を予測するのに最適です。FLACの線形予測因子には、予測係数と予測因子の順序以外に2つのパラメーターがあります。各係数が保存されるビット数（係数精度）と予測の正しいシフトです。予測は、各予測子係数に対応する過去のサンプルを掛け、指定された右シフトを適用してその合計を分割することによって形成されます。詳細については、セクション9.2.6を参照してください。 +

+
+
+
+
+

+A FLAC encoder is free to select any of the above methods to model the input. However, to ensure lossless coding, the following exceptions apply: +

+
+
+

+FLACエンコーダーは、入力をモデル化するための上記の方法のいずれかを自由に選択できます。ただし、ロスレスコーディングを確保するには、次の例外が適用されます。 +

+
+
+
+
+

+* When the samples that need to be stored do not all have the same value (i.e., the signal is not constant), a constant subframe cannot be used. +

+
+
+

+* 保存する必要があるサンプルがすべて同じ値を持っているわけではない場合（つまり、信号は一定ではありません）、一定のサブフレームを使用できません。 +

+
+
+
+
+

+* When an encoder is unable to find a fixed or linear predictor for which all residual samples are representable in 32-bit signed integers as stated in Section 9.2.7, a verbatim subframe is used. +

+
+
+

+* セクション9.2.7に記載されているように、すべての残差サンプルが32ビットの署名された整数で表される固定または線形予測因子をエンコーダが見つけることができない場合、逐語的なサブフレームが使用されます。 +

+
+
+
+
+

+For more information on fixed and linear predictors, see [Lossless-Compression] and [Robinson-TR156]. +

+
+
+

+固定および線形予測因子の詳細については、[ロブンソン-TR156]を参照してください。 +

+
+
+
+
+
+4.4. Residual Coding +
+
+
+
+4.4. 残留コーディング +
+
+
+
+
+

+If a subframe uses a predictor to approximate the audio signal, a residual is stored to "correct" the approximation to the exact value. When an effective predictor is used, the average numerical value of the residual samples is smaller than that of the samples before prediction. While having smaller values on average, it is possible that a few "outlier" residual samples are much larger than any of the original samples. Sometimes these outliers even exceed the range that the bit depth of the original audio offers. +

+
+
+

+サブフレームが予測子を使用してオーディオ信号を近似する場合、残差は正確な値の近似を「修正」するように保存されます。効果的な予測因子を使用すると、残差サンプルの平均数値値は、予測前のサンプルの平均値よりも小さくなります。平均して値が小さい一方で、いくつかの「外れ値」残差サンプルが元のサンプルのいずれよりもはるかに大きい可能性があります。これらの外れ値は、元のオーディオのビット深度が提供する範囲を超えることがあります。 +

+
+
+
+
+

+To efficiently code such a stream of relatively small numbers with an occasional outlier, Rice coding (a subset of Golomb coding) is used. Depending on how small the numbers are that have to be coded, a Rice parameter is chosen. The numerical value of each residual sample is split into two parts by dividing it by 2^(Rice parameter), creating a quotient and a remainder. The quotient is stored in unary form and the remainder in binary form. If indeed most residual samples are close to zero and a suitable Rice parameter is chosen, this form of coding, with a so-called variable-length code, uses fewer bits than the residual in unencoded form. +

+
+
+

+比較的少数のこのようなストリームを時折外れ値で効率的にコーディングするには、米コーディング（ゴロンコーディングのサブセット）が使用されます。コード化する必要がある数値がどれだけ少ないかに応じて、イネパラメーターが選択されます。各残差サンプルの数値は、2^（Riceパラメーター）で割ることにより、2つの部分に分割され、商と残りを作成します。商は単位形式で保存され、残りはバイナリ形式で保存されます。実際にほとんどの残留サンプルがゼロに近く、適切なイネパラメーターが選択されている場合、いわゆる可変長コードを使用したこの形式のコーディングは、エンコードされていない形の残差よりも少ないビットを使用します。 +

+
+
+
+
+

+As Rice codes can only handle unsigned numbers, signed numbers are zigzag encoded to a so-called folded residual. See Section 9.2.7 for a more thorough explanation. +

+
+
+

+イネコードは署名されていない数値のみを処理できるため、署名された数値は、いわゆる折り畳まれた残留物にエンコードされたzigzagです。より徹底的な説明については、セクション9.2.7を参照してください。 +

+
+
+
+
+

+Quite often, the optimal Rice parameter varies over the course of a subframe. To accommodate this, the residual can be split up into partitions, where each partition has its own Rice parameter. To keep overhead and complexity low, the number of partitions used in a subframe is limited to powers of two. +

+
+
+

+多くの場合、最適な米パラメーターはサブフレームの過程で変化します。これに対応するために、残差はパーティションに分割できます。各パーティションには独自のイネパラメーターがあります。オーバーヘッドと複雑さを低く保つために、サブフレームで使用されるパーティションの数は2つのパワーに限定されます。 +

+
+
+
+
+

+The FLAC format uses two forms of Rice coding, which only differ in the number of bits used for encoding the Rice parameter, either 4 or 5 bits. +

+
+
+

+FLAC形式では、2つのフォームのイネコーディングを使用します。これは、4ビットまたは5ビットのライスパラメーターをエンコードするために使用されるビットの数のみが異なります。 +

+
+
+
+
+
+5. Format Principles +
+
+
+
+5. 形式の原則 +
+
+
+
+
+

+FLAC has no format version information, but it does contain reserved space in several places. Future versions of the format MAY use this reserved space safely without breaking the format of older streams. Older decoders MAY choose to abort decoding when encountering data that is encoded using methods they do not recognize. Apart from reserved patterns, the format specifies forbidden patterns in certain places, meaning that the patterns MUST NOT appear in any bitstream. They are listed in the following table. +

+
+
+

+FLACにはフォーマットバージョン情報はありませんが、いくつかの場所に予約スペースが含まれています。フォーマットの将来のバージョンは、古いストリームの形式を破ることなく、この予約スペースを安全に使用する場合があります。古いデコーダーは、認識されていないメソッドを使用してエンコードされたデータに遭遇する場合にデコードを中止することを選択できます。予約されたパターンとは別に、この形式は特定の場所で禁止されたパターンを指定します。つまり、パターンはどのビットストリームにも表示されてはなりません。次の表にリストされています。 +

+
+
+
+
+ 
+            +=========================================+=============+
+            | Description                             | Reference   |
+            +=========================================+=============+
+            | Metadata block type 127                 | Section 8.1 |
+            +-----------------------------------------+-------------+
+            | Minimum and maximum block sizes smaller | Section 8.2 |
+            | than 16 in streaminfo metadata block    |             |
+            +-----------------------------------------+-------------+
+            | Sample rate bits 0b1111                 | Section     |
+            |                                         | 9.1.2       |
+            +-----------------------------------------+-------------+
+            | Uncommon block size 65536               | Section     |
+            |                                         | 9.1.6       |
+            +-----------------------------------------+-------------+
+            | Predictor coefficient precision bits    | Section     |
+            | 0b1111                                  | 9.2.6       |
+            +-----------------------------------------+-------------+
+            | Negative predictor right shift          | Section     |
+            |                                         | 9.2.6       |
+            +-----------------------------------------+-------------+
+
+                                     Table 1
+
+
+
+
+
+

+All numbers used in a FLAC bitstream are integers; there are no floating-point representations. All numbers are big-endian coded, except the field lengths used in Vorbis comments (see Section 8.6), which are little-endian coded. This exception for Vorbis comments is to keep as much commonality as possible with Vorbis comments as used by the Vorbis codec (see [Vorbis]). All numbers are unsigned except linear predictor coefficients, the linear prediction shift (see Section 9.2.6), and numbers that directly represent samples, which are signed. None of these restrictions apply to application metadata blocks or to Vorbis comment field contents. +

+
+
+

+FLACビットストリームで使用されるすべての数値は整数です。浮動小数点表現はありません。すべての数字は、Vorbisのコメントで使用されているフィールドの長さ（セクション8.6を参照）を除き、小さなエンディアンコード化されています。Vorbisコメントのこの例外は、Vorbis Codecで使用されているVorbisコメントと可能な限り多くの共通性を維持することです（[Vorbis]を参照）。すべての数値は、線形予測係数、線形予測シフト（セクション9.2.6を参照）、および署名されたサンプルを直接表す数値を除き、署名されていません。これらの制限はいずれも、アプリケーションメタデータブロックやVorbisコメントフィールドの内容には適用されません。 +

+
+
+
+
+

+All samples encoded to and decoded from the FLAC format MUST be in a signed representation. +

+
+
+

+FLAC形式にエンコードされてデコードされたすべてのサンプルは、署名された表現である必要があります。 +

+
+
+
+
+

+There are several ways to convert unsigned sample representations to signed sample representations, but the coding methods provided by the FLAC format work best on samples that have numerical values that are centered around zero, i.e., have no DC offset. In most unsigned audio formats, signals are centered around halfway within the range of the unsigned integer type used. If that is the case, converting sample representations by first copying the number to a signed integer with a sufficient range and then subtracting half of the range of the unsigned integer type results in a signal with samples centered around 0. +

+
+
+

+署名されていないサンプル表現を署名されたサンプル表現に変換する方法はいくつかありますが、FLAC形式によって提供されるコーディング方法は、ゼロを中心とする数値、つまりDCオフセットを持たないサンプルで最適に機能します。ほとんどの符号なしのオーディオ形式では、信号は使用されている署名されていない整数型の範囲内の中心にあります。その場合、最初に数字を十分な範囲の署名整数にコピーしてサンプル表現を変換し、次に署名されていない整数型の範囲の半分を減算すると、サンプルが0を中心となる信号が得られます。 +

+
+
+
+
+

+Unary coding in a FLAC bitstream is done with zero bits terminated with a one bit, e.g., the number 5 is coded unary as 0b000001. This prevents the frame sync code from appearing in unary-coded numbers. +

+
+
+

+FLACビットストリームでの単位コーディングは、1ビットで終了したゼロビットで行われます。たとえば、ナンバー5は0B000001と統一されます。これにより、フレーム同期コードが単位コーディングされた数字で表示されないようにします。 +

+
+
+
+
+

+When a FLAC file contains data that is forbidden or otherwise not valid, decoder behavior is left unspecified. A decoder MAY choose to stop decoding upon encountering such data. Examples of such data include the following: +

+
+
+

+FLACファイルに禁止されている、または無効なデータが含まれている場合、デコーダーの動作は不特定のままになります。デコーダーは、そのようなデータに遭遇したときにデコードを停止することを選択できます。そのようなデータの例には、以下が含まれます。 +

+
+
+
+
+

+* One or more decoded sample values exceed the range offered by the bit depth as coded for that frame. For example, in a frame with a bit depth of 8 bits, any samples not in the inclusive range from -128 to 127 are not valid. +

+
+
+

+* 1つ以上のデコードされたサンプル値は、そのフレームにコード化されたビット深度によって提供される範囲を超えています。たとえば、8ビットの深さが少しあるフレームでは、-128〜127までの包括的な範囲にないサンプルは無効です。 +

+
+
+
+
+

+* The number of wasted bits (see Section 9.2.2) used by a subframe is such that the bit depth of that subframe (see Section 9.2.3 for a description of subframe bit depth) equals zero or is negative. +

+
+
+

+* サブフレームで使用される無駄なビットの数（セクション9.2.2を参照）は、そのサブフレームのビット深さ（サブフレームビット深度の説明についてはセクション9.2.3を参照）がゼロに等しいか負のものです。 +

+
+
+
+
+

+* A frame header Cyclic Redundancy Check (CRC) (see Section 9.1.8) or frame footer CRC (see Section 9.3) does not validate. +

+
+
+

+* フレームヘッダーサイクリック冗長チェック（CRC）（セクション9.1.8を参照）またはフレームフッターCRC（セクション9.3を参照）は検証しません。 +

+
+
+
+
+

+* One of the forbidden bit patterns described in Table 1 is used. +

+
+
+

+* 表1で説明する禁じられたビットパターンの1つが使用されます。 +

+
+
+
+
+
+6. Format Layout Overview +
+
+
+
+6. フォーマットレイアウトの概要 +
+
+
+
+
+

+A FLAC bitstream consists of the fLaC (i.e., 0x664C6143) marker at the beginning of the stream, followed by a mandatory metadata block (called the streaminfo metadata block), any number of other metadata blocks, and then the audio frames. +

+
+
+

+FLACビットストリームは、ストリームの先頭にFLAC（つまり、0x664C6143）マーカーで構成され、その後、必須のメタデータブロック（Streaminfoメタデータブロックと呼ばれる）、他の任意の数のメタデータブロック、次にオーディオフレームが続きます。 +

+
+
+
+
+

+FLAC supports 127 kinds of metadata blocks; currently, 7 kinds are defined in Section 8. +

+
+
+

+FLACは、127種類のメタデータブロックをサポートしています。現在、7種類はセクション8で定義されています。 +

+
+
+
+
+

+The audio data is composed of one or more audio frames. Each frame consists of a frame header that contains a sync code, information about the frame (like the block size, sample rate, and number of channels), and an 8-bit CRC. The frame header also contains either the sample number of the first sample in the frame (for variable block size streams) or the frame number (for fixed block size streams). This allows for fast, sample-accurate seeking to be performed. Following the frame header are encoded subframes, one for each channel. The frame is then zero-padded to a byte boundary and finished with a frame footer containing a checksum for the frame. Each subframe has its own header that specifies how the subframe is encoded. +

+
+
+

+オーディオデータは、1つ以上のオーディオフレームで構成されています。各フレームは、同期コード、フレームに関する情報（ブロックサイズ、サンプルレート、チャネル数など）、および8ビットCRCを含むフレームヘッダーで構成されています。フレームヘッダーには、フレーム内の最初のサンプルのサンプル番号（可変ブロックサイズストリームの場合）またはフレーム番号（固定ブロックサイズストリームの場合）も含まれます。これにより、迅速でサンプルが順応性の高い探求が可能になります。フォローフレームヘッダーは、各チャネルに1つのエンコードされたサブフレームです。その後、フレームはバイト境界にゼロパッドされ、フレームのチェックサムを含むフレームフッターで仕上げられます。各サブフレームには、サブフレームのエンコード方法を指定する独自のヘッダーがあります。 +

+
+
+
+
+

+In order to allow a decoder to start decoding at any place in the stream, each frame starts with a byte-aligned 15-bit sync code. However, since it is not guaranteed that the sync code does not appear elsewhere in the frame, the decoder can check that it synced correctly by parsing the rest of the frame header and validating the frame header CRC. +

+
+
+

+デコーダーがストリーム内の任意の場所でデコードを開始できるようにするために、各フレームはバイトに並べられた15ビット同期コードで始まります。ただし、同期コードがフレームの他の場所に表示されないことは保証されていないため、デコーダーはフレームヘッダーの残りの部分を解析し、フレームヘッダーCRCを検証することにより正しく同期していることを確認できます。 +

+
+
+
+
+

+Furthermore, to allow a decoder to start decoding at any place in the stream even without having received a streaminfo metadata block, each frame header contains some basic information about the stream. This information includes sample rate, bits per sample, number of channels, etc. Since the frame header is overhead, it has a direct effect on the compression ratio. To keep the frame header as small as possible, FLAC uses lookup tables for the most commonly used values for frame properties. When a certain property has a value that is not covered by the lookup table, the decoder is directed to find the value of that property (for example, the sample rate) at the end of the frame header or in the streaminfo metadata block. If a frame header refers to the streaminfo metadata block, the file is not "streamable"; see Section 7 for details. By using lookup tables, the file is streamable and the frame header size is small for the most common forms of audio data. +

+
+
+

+さらに、Streaminfoメタデータブロックを受け取っていなくても、デコーダーがストリーム内の任意の場所でデコードを開始できるようにするために、各フレームヘッダーにはストリームに関する基本情報が含まれています。この情報には、サンプルレート、サンプルあたりのビット、チャネル数などが含まれます。フレームヘッダーは頭上であるため、圧縮率に直接的な影響があります。フレームヘッダーをできるだけ小さく保つために、FLACはフレームプロパティで最も一般的に使用される値にルックアップテーブルを使用します。特定のプロパティにルックアップテーブルでカバーされていない値がある場合、デコーダーは、フレームヘッダーの端またはstreaminfoメタデータブロックでそのプロパティの値（サンプルレートなど）を見つけるように指示されます。フレームヘッダーがStreaminfoメタデータブロックを指す場合、ファイルは「ストリーミング可能」ではありません。詳細については、セクション7を参照してください。ルックアップテーブルを使用することにより、ファイルはストリーミング可能であり、最も一般的なフォームのオーディオデータに対してフレームヘッダーサイズは小さくなります。 +

+
+
+
+
+

+Individual subframes (one for each channel) are coded separately within a frame and appear serially in the stream. In other words, the encoded audio data is NOT channel-interleaved. This reduces decoder complexity at the cost of requiring larger decode buffers. Each subframe has its own header specifying the attributes of the subframe, like prediction method and order, residual coding parameters, etc. Each subframe header is followed by the encoded audio data for that channel. +

+
+
+

+個々のサブフレーム（各チャネルに1つ）は、フレーム内で個別にコーディングされ、ストリーム内に連続的に表示されます。言い換えれば、エンコードされたオーディオデータはチャネル介入ではありません。これにより、より大きなデコードバッファーを必要とするコストでデコーダーの複雑さが減少します。各サブフレームには、予測方法や順序、残留コーディングパラメーターなど、サブフレームの属性を指定する独自のヘッダーがあります。各サブフレームヘッダーの後に、そのチャネルのエンコードされたオーディオデータが続きます。 +

+
+
+
+
+
+7. Streamable Subset +
+
+
+
+7. ストリーミング可能なサブセット +
+
+
+
+
+

+The FLAC format specifies a subset of itself as the FLAC streamable subset. The purpose of this is to ensure that any streams encoded according to this subset are truly "streamable", meaning that a decoder that cannot seek within the stream can still pick up in the middle of the stream and start decoding. It also makes hardware decoder implementations more practical by limiting the encoding parameters in such a way that decoder buffer sizes and other resource requirements can be easily determined. The streamable subset makes the following limitations on what MAY be used in the stream: +

+
+
+

+FLAC形式は、FLACストリーミング可能なサブセットとしてそれ自体のサブセットを指定します。これの目的は、このサブセットに従ってエンコードされたストリームが本当に「ストリーミング可能」であることを確認することです。つまり、ストリーム内で探すことができないデコーダーは、ストリームの中央でピックアップしてデコードを開始できることを意味します。また、デコーダーバッファーサイズやその他のリソース要件を簡単に決定できるように、エンコードパラメーターを制限することにより、ハードウェアデコーダーの実装をより実用的にします。ストリーム可能なサブセットは、ストリームで使用できるものに次の制限を作成します。 +

+
+
+
+
+

+* The sample rate bits (see Section 9.1.2) in the frame header MUST be 0b0001-0b1110, i.e., the frame header MUST NOT refer to the streaminfo metadata block to describe the sample rate. +

+
+
+

+* フレームヘッダーのサンプルレートビット（セクション9.1.2を参照）は0B0001-0B1110でなければなりません。つまり、フレームヘッダーは、サンプルレートを記述するためにStreaminfoメタデータブロックを参照してはなりません。 +

+
+
+
+
+

+* The bit depth bits (see Section 9.1.4) in the frame header MUST be 0b001-0b111, i.e., the frame header MUST NOT refer to the streaminfo metadata block to describe the bit depth. +

+
+
+

+* フレームヘッダーのビット深度ビット（セクション9.1.4を参照）は0B001-0B111でなければなりません。つまり、フレームヘッダーは、ビット深度を記述するためにStreaminfoメタデータブロックを参照してはなりません。 +

+
+
+
+
+

+* The stream MUST NOT contain blocks with more than 16384 interchannel samples, i.e., the maximum block size must not be larger than 16384. +

+
+
+

+* ストリームには、16384を超えるチャンネルサンプルを持つブロックを含めてはなりません。つまり、最大ブロックサイズは16384を超えてはなりません。 +

+
+
+
+
+

+* Audio with a sample rate less than or equal to 48000 Hz MUST NOT be contained in blocks with more than 4608 interchannel samples, i.e., the maximum block size used for this audio must not be larger than 4608. +

+
+
+

+* サンプルレートが48000 Hz以下のオーディオは、4608を超えるチャネルサンプルを備えたブロックに含める必要はありません。つまり、このオーディオに使用される最大ブロックサイズは4608を超えてはなりません。 +

+
+
+
+
+

+* Linear prediction subframes (see Section 9.2.6) containing audio with a sample rate less than or equal to 48000 Hz MUST have a predictor order less than or equal to 12, i.e., the subframe type bits in the subframe header (see Section 9.2.1) MUST NOT be 0b101100-0b111111. +

+
+
+

+* 48000 Hz以下のサンプルレートを含むオーディオを含む線形予測サブフレーム（セクション9.2.6を参照）は、12以下の予測順、つまりサブフレームヘッダーのサブフレームタイプビット（セクション9.2を参照してください。1）0B101100-0B111111にしてはなりません。 +

+
+
+
+
+

+* The Rice partition order (see Section 9.2.7) MUST be less than or equal to 8. +

+
+
+

+* イネの分配順序（セクション9.2.7を参照）は、8以下でなければなりません。 +

+
+
+
+
+

+* The channel ordering MUST be equal to one defined in Section 9.1.3, i.e., the FLAC file MUST NOT need a WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag to describe the channel ordering. See Section 8.6.2 for details. +

+
+
+

+* チャネルの順序付けは、セクション9.1.3で定義されているものに等しくなければなりません。つまり、FLACファイルは、チャネルの順序付けを説明するために波形Xtensible_Channel_Maskタグを必要としないはずです。詳細については、セクション8.6.2を参照してください。 +

+
+
+
+
+
+8. File-Level Metadata +
+
+
+
+8. ファイルレベルのメタデータ +
+
+
+
+
+

+At the start of a FLAC file or stream, following the fLaC ASCII file signature, one or more metadata blocks MUST be present before any audio frames appear. The first metadata block MUST be a streaminfo metadata block. +

+
+
+

+FLACファイルまたはストリームの開始時に、FLAC ASCIIファイルの署名に続いて、オーディオフレームが表示される前に1つ以上のメタデータブロックが存在する必要があります。最初のメタデータブロックは、Streaminfoメタデータブロックでなければなりません。 +

+
+
+
+
+
+8.1. Metadata Block Header +
+
+
+
+8.1. メタデータブロックヘッダー +
+
+
+
+
+

+Each metadata block starts with a 4-byte header. The first bit in this header flags whether a metadata block is the last one. It is 0 when other metadata blocks follow; otherwise, it is 1. The 7 remaining bits of the first header byte contain the type of the metadata block as an unsigned number between 0 and 126, according to the following table. A value of 127 (i.e., 0b1111111) is forbidden. The three bytes that follow code for the size of the metadata block in bytes, excluding the 4 header bytes, as an unsigned number coded big-endian. +

+
+
+

+各メタデータブロックは、4バイトヘッダーで始まります。このヘッダーの最初のビットは、メタデータブロックが最後のブロックであるかどうかにかかわらず、フラグを立てます。他のメタデータブロックが続く場合は0です。それ以外の場合は、1です。最初のヘッダーバイトの残りの7ビットには、次の表によると、メタデータブロックのタイプが0〜126の間の符号なしの数値として含まれています。127の値（つまり、0B1111111）は禁止されています。メタデータブロックのサイズのコードに従う3バイトは、4つのヘッダーバイトを除く、符号なしの数字をコード化されたビッグエンディアンとして除外します。 +

+
+
+
+
+ 
+  +=========+=======================================================+
+  | Value   | Metadata Block Type                                   |
+  +=========+=======================================================+
+  | 0       | Streaminfo                                            |
+  +---------+-------------------------------------------------------+
+  | 1       | Padding                                               |
+  +---------+-------------------------------------------------------+
+  | 2       | Application                                           |
+  +---------+-------------------------------------------------------+
+  | 3       | Seek table                                            |
+  +---------+-------------------------------------------------------+
+  | 4       | Vorbis comment                                        |
+  +---------+-------------------------------------------------------+
+  | 5       | Cuesheet                                              |
+  +---------+-------------------------------------------------------+
+  | 6       | Picture                                               |
+  +---------+-------------------------------------------------------+
+  | 7 - 126 | Reserved                                              |
+  +---------+-------------------------------------------------------+
+  | 127     | Forbidden (to avoid confusion with a frame sync code) |
+  +---------+-------------------------------------------------------+
+
+                                Table 2
+
+
+
+
+
+
+8.2. Streaminfo +
+
+
+
+8.2. Streaminfo +
+
+
+
+
+

+The streaminfo metadata block has information about the whole stream, such as sample rate, number of channels, total number of samples, etc. It MUST be present as the first metadata block in the stream. Other metadata blocks MAY follow. There MUST be no more than one streaminfo metadata block per FLAC stream. +

+
+
+

+Streaminfoメタデータブロックには、サンプルレート、チャネルの数、サンプルの総数など、ストリーム全体に関する情報があります。ストリームの最初のメタデータブロックとして存在する必要があります。他のメタデータブロックが続く場合があります。FLACストリームごとにStreaminfoメタデータブロックが1つしかない必要があります。 +

+
+
+
+
+

+If the streaminfo metadata block contains incorrect or incomplete information, decoder behavior is left unspecified (i.e., it is up to the decoder implementation). A decoder MAY choose to stop further decoding when the information supplied by the streaminfo metadata block turns out to be incorrect or contains forbidden values. A decoder accepting information from the streaminfo metadata block (most significantly, the maximum frame size, maximum block size, number of audio channels, number of bits per sample, and total number of samples) without doing further checks during decoding of audio frames could be vulnerable to buffer overflows. See also Section 11. +

+
+
+

+Streaminfoメタデータブロックに誤った情報または不完全な情報が含まれている場合、デコーダーの動作は不特定のままになります（つまり、デコーダーの実装次第です）。Decoderは、Streaminfoメタデータブロックによって提供された情報が正しくないか、禁止された値が含まれていることが判明した場合、さらにデコードを停止することを選択できます。Streaminfoメタデータブロックからの情報を受け入れるデコーダー（最も重要なことは、最大フレームサイズ、最大ブロックサイズ、オーディオチャネル数、サンプルあたりのビット数、およびサンプルの総数）を選択せずに、オーディオフレームのデコード中にさらにチェックすることはできません。バッファオーバーフローに対して脆弱です。セクション11も参照してください。 +

+
+
+
+
+

+The following table describes the streaminfo metadata block in order, excluding the metadata block header. +

+
+
+

+次の表は、メタデータブロックヘッダーを除く、Streaminfoメタデータブロックを順番に説明しています。 +

+
+
+
+
+ 
+        +========+=================================================+
+        | Data   | Description                                     |
+        +========+=================================================+
+        | u(16)  | The minimum block size (in samples) used in the |
+        |        | stream, excluding the last block.               |
+        +--------+-------------------------------------------------+
+        | u(16)  | The maximum block size (in samples) used in the |
+        |        | stream.                                         |
+        +--------+-------------------------------------------------+
+        | u(24)  | The minimum frame size (in bytes) used in the   |
+        |        | stream.  A value of 0 signifies that the value  |
+        |        | is not known.                                   |
+        +--------+-------------------------------------------------+
+        | u(24)  | The maximum frame size (in bytes) used in the   |
+        |        | stream.  A value of 0 signifies that the value  |
+        |        | is not known.                                   |
+        +--------+-------------------------------------------------+
+        | u(20)  | Sample rate in Hz.                              |
+        +--------+-------------------------------------------------+
+        | u(3)   | (number of channels)-1.  FLAC supports from 1   |
+        |        | to 8 channels.                                  |
+        +--------+-------------------------------------------------+
+        | u(5)   | (bits per sample)-1.  FLAC supports from 4 to   |
+        |        | 32 bits per sample.                             |
+        +--------+-------------------------------------------------+
+        | u(36)  | Total number of interchannel samples in the     |
+        |        | stream.  A value of 0 here means the number of  |
+        |        | total samples is unknown.                       |
+        +--------+-------------------------------------------------+
+        | u(128) | MD5 checksum of the unencoded audio data.  This |
+        |        | allows the decoder to determine if an error     |
+        |        | exists in the audio data even when, despite the |
+        |        | error, the bitstream itself is valid.  A value  |
+        |        | of 0 signifies that the value is not known.     |
+        +--------+-------------------------------------------------+
+
+                                  Table 3
+
+
+
+
+
+

+The minimum block size and the maximum block size MUST be in the 16-65535 range. The minimum block size MUST be equal to or less than the maximum block size. +

+
+
+

+最小ブロックサイズと最大ブロックサイズは、16-65535の範囲でなければなりません。最小ブロックサイズは、最大ブロックサイズ以下でなければなりません。 +

+
+
+
+
+

+Any frame but the last one MUST have a block size equal to or greater than the minimum block size and MUST have a block size equal to or less than the maximum block size. The last frame MUST have a block size equal to or less than the maximum block size; it does not have to comply to the minimum block size because the block size of that frame must be able to accommodate the length of the audio data the stream contains. +

+
+
+

+最後のフレーム以外の任意のフレームには、最小ブロックサイズ以上のブロックサイズが必要であり、最大ブロックサイズ以下のブロックサイズが必要です。最後のフレームには、最大ブロックサイズ以下のブロックサイズが必要です。そのフレームのブロックサイズは、ストリームに含まれるオーディオデータの長さに対応できる必要があるため、最小ブロックサイズに準拠する必要はありません。 +

+
+
+
+
+

+If the minimum block size is equal to the maximum block size, the file contains a fixed block size stream, as the minimum block size excludes the last block. Note that in the case of a stream with a variable block size, the actual maximum block size MAY be smaller than the maximum block size listed in the streaminfo metadata block, and the actual smallest block size excluding the last block MAY be larger than the minimum block size listed in the streaminfo metadata block. This is because the encoder has to write these fields before receiving any input audio data and cannot know beforehand what block sizes it will use, only between what bounds the block sizes will be chosen. +

+
+
+

+最小ブロックサイズが最大ブロックサイズに等しい場合、最小ブロックサイズは最後のブロックを除外するため、ファイルには固定ブロックサイズストリームが含まれます。可変ブロックサイズのストリームの場合、実際の最大ブロックサイズはStreaminfoメタデータブロックにリストされている最大ブロックサイズよりも小さく、最後のブロックを除く実際の最小のブロックサイズは最小値よりも大きい場合があることに注意してください。Streaminfoメタデータブロックにリストされているブロックサイズ。これは、入力オーディオデータを受信する前にエンコーダーがこれらのフィールドを記述する必要があり、使用するブロックサイズを事前に知ることができないためです。 +

+
+
+
+
+

+The sample rate MUST NOT be 0 when the FLAC file contains audio. A sample rate of 0 MAY be used when non-audio is represented. This is useful if data is encoded that is not along a time axis or when the sample rate of the data lies outside the range that FLAC can represent in the streaminfo metadata block. If a sample rate of 0 is used, it is recommended to store the meaning of the encoded content in a Vorbis comment field (see Section 8.6) or an application metadata block (see Section 8.4). This document does not define such metadata. +

+
+
+

+FLACファイルにオーディオが含まれている場合、サンプルレートは0ではありません。非オーディオが表される場合、0のサンプルレートを使用できます。これは、時間軸に沿っていないデータがエンコードされている場合、またはデータのサンプルレートがFLACがStreaminfoメタデータブロックで表すことができる範囲外にある場合に役立ちます。0のサンプルレートを使用する場合は、エンコードされたコンテンツの意味をVorbisコメントフィールド（セクション8.6を参照）またはアプリケーションメタデータブロック（セクション8.4を参照）に保存することをお勧めします。このドキュメントは、そのようなメタデータを定義しません。 +

+
+
+
+
+

+The MD5 checksum is computed by applying the MD5 message-digest algorithm in [RFC1321]. The message to this algorithm consists of all the samples of all channels interleaved, represented in signed, little-endian form. This interleaving is on a per-sample basis, so for a stereo file, this means the first sample of the first channel, then the first sample of the second channel, then the second sample of the first channel, etc. Before computing the checksum, all samples must be byte-aligned. If the bit depth is not a whole number of bytes, the value of each sample is sign-extended to the next whole number of bytes. +

+
+
+

+MD5チェックサムは、[RFC1321]にMD5メッセージダイジェストアルゴリズムを適用することにより計算されます。このアルゴリズムへのメッセージは、署名された小さなエンディアン形式で表されるインターリーブされたすべてのチャネルのすべてのサンプルで構成されています。このインターリーブはサンプルごとにあるため、ステレオファイルの場合、これは最初のチャネルの最初のサンプル、次に2番目のチャネルの最初のサンプル、次に最初のチャネルの2番目のサンプルなどを意味します。、すべてのサンプルをバイトアリーで整列する必要があります。ビットの深さがバイトの整数でない場合、各サンプルの値は、次のバイトの全部に標識拡張されます。 +

+
+
+
+
+

+In the case of a 2-channel stream with 6-bit samples, bits will be lined up as follows: +

+
+
+

+6ビットサンプルを備えた2チャンネルストリームの場合、ビットは次のように並んでいます。 +

+
+
+
+
+ 
+   SSAAAAAASSBBBBBBSSCCCCCC
+   ^   ^   ^   ^   ^   ^
+   |   |   |   |   |  Bits of 2nd sample of 1st channel
+   |   |   |   |  Sign extension bits of 2nd sample of 2nd channel
+   |   |   |  Bits of 1st sample of 2nd channel
+   |   |  Sign extension bits of 1st sample of 2nd channel
+   |  Bits of 1st sample of 1st channel
+   Sign extension bits of 1st sample of 1st channel
+
+
+
+
+
+

+In the case of a 1-channel stream with 12-bit samples, bits are lined up in little-endian byte order as follows: +

+
+
+

+12ビットサンプルを備えた1チャンネルストリームの場合、ビットは次のようにリトルエンディアンバイトの順序で並んでいます。 +

+
+
+
+
+ 
+   AAAAAAAASSSSAAAABBBBBBBBSSSSBBBB
+      ^     ^   ^   ^       ^   ^
+      |     |   |   |       |  Most-significant 4 bits of 2nd sample
+      |     |   |   | Sign extension bits of 2nd sample
+      |     |   |  Least-significant 8 bits of 2nd sample
+      |     |  Most-significant 4 bits of 1st sample
+      |    Sign extension bits of 1st sample
+     Least-significant 8 bits of 1st sample
+
+
+
+
+
+
+8.3. Padding +
+
+
+
+8.3. パディング +
+
+
+
+
+

+The padding metadata block allows for an arbitrary amount of padding. This block is useful when it is known that metadata will be edited after encoding; the user can instruct the encoder to reserve a padding block of sufficient size so that when metadata is added, it will simply overwrite the padding (which is relatively quick) instead of having to insert it into the existing file (which would normally require rewriting the entire file). There MAY be one or more padding metadata blocks per FLAC stream. +

+
+
+

+パディングメタデータブロックは、任意の量のパディングを可能にします。このブロックは、メタデータがエンコード後に編集されることがわかっている場合に役立ちます。ユーザーは、メタデータが追加されると、既存のファイルに挿入する代わりにパディング（比較的速い）を単純に上書きするように、エンコーダーに十分なサイズのパディングブロックを予約するように指示できます（通常は、書き換えが必要になります。ファイル全体）。FLACストリームごとに1つ以上のパディングメタデータブロックがある場合があります。 +

+
+
+
+
+ 
+      +======+======================================================+
+      | Data | Description                                          |
+      +======+======================================================+
+      | u(n) | n "0" bits (n MUST be a multiple of 8, i.e., a whole |
+      |      | number of bytes, and MAY be zero). n is 8 times the  |
+      |      | size described in the metadata block header.         |
+      +------+------------------------------------------------------+
+
+                                  Table 4
+
+
+
+
+
+
+8.4. Application +
+
+
+
+8.4. 応用 +
+
+
+
+
+

+The application metadata block is for use by third-party applications. The only mandatory field is a 32-bit application identifier (application ID). Application IDs are registered in the IANA "FLAC Application Metadata Block IDs" registry (see Section 12.2). +

+
+
+

+アプリケーションメタデータブロックは、サードパーティアプリケーションで使用するためのものです。唯一の必須フィールドは、32ビットアプリケーション識別子（アプリケーションID）です。アプリケーションIDは、IANA「FLACアプリケーションメタデータブロックID」レジストリに登録されています（セクション12.2を参照）。 +

+
+
+
+
+ 
+        +=======+===================================================+
+        | Data  | Description                                       |
+        +=======+===================================================+
+        | u(32) | Registered application ID.                        |
+        +-------+---------------------------------------------------+
+        | u(n)  | Application data (n MUST be a multiple of 8,      |
+        |       | i.e., a whole number of bytes). n is 8 times the  |
+        |       | size described in the metadata block header minus |
+        |       | the 32 bits already used for the application ID.  |
+        +-------+---------------------------------------------------+
+
+                                   Table 5
+
+
+
+
+
+
+8.5. Seek Table +
+
+
+
+8.5. テーブルを探します +
+
+
+
+
+

+The seek table metadata block can be used to store seek points. It is possible to seek to any given sample in a FLAC stream without a seek table, but the delay can be unpredictable since the bitrate may vary widely within a stream. By adding seek points to a stream, this delay can be significantly reduced. There MUST NOT be more than one seek table metadata block in a stream, but the table can have any number of seek points. +

+
+
+

+シークテーブルメタデータブロックを使用してシークポイントを保存できます。シークテーブルなしでFLACストリーム内の特定のサンプルを探すことは可能ですが、ビットレートはストリーム内で大きく異なるため、遅延は予測不可能になる可能性があります。ストリームにシークポイントを追加することにより、この遅延を大幅に減らすことができます。ストリームには1つ以上のシークテーブルメタデータブロックがありませんが、テーブルには任意の数のシークポイントがあります。 +

+
+
+
+
+

+Each seek point takes 18 bytes, so a seek table with 1% resolution within a stream adds less than 2 kilobytes of data. The number of seek points is implied by the size described in the metadata block header, i.e., equal to size / 18. There is also a special "placeholder" seek point that will be ignored by decoders but can be used to reserve space for future seek point insertion. +

+
+
+

+各シークポイントには18バイトがかかるため、ストリーム内に1％の解像度を持つシークテーブルは、2キロバイト未満のデータを追加します。シークポイントの数は、メタデータブロックヘッダー、つまりサイズ / 18に等しいサイズによって暗示されます。また、デコーダーによって無視されるが、将来のためにスペースを予約するために使用できる特別な「プレースホルダー」シークポイントもあります。ポイント挿入を求めます。 +

+
+
+
+
+ 
+                        +=============+=============================+
+                        | Data        | Description                 |
+                        +=============+=============================+
+                        | Seek points | Zero or more seek points as |
+                        |             | defined in Section 8.5.1.   |
+                        +-------------+-----------------------------+
+
+                                           Table 6
+
+
+
+
+
+

+A seek table is generally not usable for seeking in a FLAC file embedded in a container (see Section 10), as such containers usually interleave FLAC data with other data and the offsets used in seek points are those of an unmuxed FLAC stream. Also, containers often provide their own seeking methods. However, it is possible to store the seek table in the container along with other metadata when muxing a FLAC file, so this stored seek table can be restored when demuxing the FLAC stream into a standalone FLAC file. +

+
+
+

+シークテーブルは、通常、コンテナに埋め込まれたFLACファイルを探すために使用できません（セクション10を参照）。そのようなコンテナは通常、FLACデータを他のデータとインターリーブし、シークポイントで使用されるオフセットは不合理なFLACストリームのものです。また、コンテナは多くの場合、独自のシーキング方法を提供します。ただし、FLACファイルをMuxingするときにSeekテーブルを他のメタデータとともにコンテナに保存することができます。そのため、FLACストリームをスタンドアロンFLACファイルに分類するときに、この保存されたシークテーブルを復元できます。 +

+
+
+
+
+
+8.5.1. Seek Point +
+
+
+
+8.5.1. シークポイント +
+
+
+
+
+ 
++=======+==========================================================+
+| Data  | Description                                              |
++=======+==========================================================+
+| u(64) | Sample number of the first sample in the target frame or |
+|       | 0xFFFFFFFFFFFFFFFF for a placeholder point.              |
++-------+----------------------------------------------------------+
+| u(64) | Offset (in bytes) from the first byte of the first frame |
+|       | header to the first byte of the target frame's header.   |
++-------+----------------------------------------------------------+
+| u(16) | Number of samples in the target frame.                   |
++-------+----------------------------------------------------------+
+
+                              Table 7
+
+
+
+
+
+

+Notes: +

+
+
+

+注： +

+
+
+
+
+

+* For placeholder points, the second and third field values are undefined. +

+
+
+

+* プレースホルダーポイントの場合、2番目と3番目のフィールド値は未定義です。 +

+
+
+
+
+

+* Seek points within a table MUST be sorted in ascending order by sample number. +

+
+
+

+* テーブル内のシークポイントは、サンプル番号で昇順でソートする必要があります。 +

+
+
+
+
+

+* Seek points within a table MUST be unique by sample number, with the exception of placeholder points. +

+
+
+

+* テーブル内のシークポイントは、プレースホルダーポイントを除き、サンプル番号で一意でなければなりません。 +

+
+
+
+
+

+* The previous two notes imply that there MAY be any number of placeholder points, but they MUST all occur at the end of the table. +

+
+
+

+* 前の2つのメモは、プレースホルダーポイントの数が存在する可能性があることを意味しますが、それらはすべてテーブルの端で発生する必要があります。 +

+
+
+
+
+

+* The sample offsets are those of an unmuxed FLAC stream. The offsets MUST NOT be updated on muxing to reflect the new offsets of FLAC frames in a container. +

+
+
+

+* サンプルオフセットは、不測のないFLACストリームのオフセットです。オフセットは、コンテナ内のFLACフレームの新しいオフセットを反映するために、マクシングで更新してはなりません。 +

+
+
+
+
+
+8.6. Vorbis Comment +
+
+
+
+8.6. Vorbisコメント +
+
+
+
+
+

+A Vorbis comment metadata block contains human-readable information coded in UTF-8. The name "Vorbis comment" points to the fact that the Vorbis codec stores such metadata in almost the same way (see [Vorbis]). A Vorbis comment metadata block consists of a vendor string optionally followed by a number of fields, which are pairs of field names and field contents. The vendor string contains the name of the program that generated the file or stream. The fields contain metadata describing various aspects of the contained audio. Many users refer to these fields as "FLAC tags" or simply as "tags". A FLAC file MUST NOT contain more than one Vorbis comment metadata block. +

+
+
+

+Vorbisコメントメタデータブロックには、UTF-8でコーディングされた人間の読み取り可能な情報が含まれています。「Vorbis Comment」という名前は、Vorbis Codecがそのようなメタデータをほぼ同じ方法で保存するという事実を示しています（[Vorbis]を参照）。Vorbisコメントメタデータブロックは、オプションでフィールド名とフィールドのコンテンツのペアである多くのフィールドがオプションで続くベンダー文字列で構成されています。ベンダー文字列には、ファイルまたはストリームを生成したプログラムの名前が含まれています。フィールドには、含まれるオーディオのさまざまな側面を説明するメタデータが含まれています。多くのユーザーは、これらのフィールドを「FLACタグ」または単に「タグ」と呼んでいます。FLACファイルには、複数のVorbisコメントメタデータブロックを含めることはできません。 +

+
+
+
+
+

+In a Vorbis comment metadata block, the metadata block header is directly followed by 4 bytes containing the length in bytes of the vendor string as an unsigned number coded little-endian. The vendor string follows, is UTF-8 coded and is not terminated in any way. +

+
+
+

+Vorbisコメントメタデータブロックでは、メタデータブロックヘッダーに直接続いて、ベンダー文字列の長さを符号なしの数字のコード化された小さなエンディアンとして含む4バイトが続きます。ベンダー文字列が続き、UTF-8コード化されており、いかなる方法でも終了しません。 +

+
+
+
+
+

+Following the vendor string are 4 bytes containing the number of fields that are in the Vorbis comment block, stored as an unsigned number coded little-endian. If this number is non-zero, it is followed by the fields themselves, each of which is stored with a 4-byte length. For each field, the field length in bytes is stored as a 4-byte unsigned number coded little-endian. The field itself follows it. Like the vendor string, the field is UTF-8 coded and not terminated in any way. +

+
+
+

+ベンダーの文字列に続くのは、署名されていない番号コード化された小さなエンディアンとして保存されているVorbisコメントブロックにあるフィールドの数を含む4バイトです。この数値がゼロ以外の場合、フィールド自体が続き、それぞれが4バイトの長さで保存されます。各フィールドについて、バイト単位のフィールドの長さは、4バイトの符号なしの数字コード付きリトルエンディアンとして保存されます。フィールド自体がそれに続きます。ベンダー文字列のように、フィールドはUTF-8コード化されており、いかなる方法でも終了しません。 +

+
+
+
+
+

+Each field consists of a field name and field contents, separated by an = character. The field name MUST only consist of UTF-8 code points U+0020 through U+007E, excluding U+003D, which is the = character. In other words, the field name can contain all printable ASCII characters except the equals sign. The evaluation of the field names MUST be case insensitive, so U+0041 through 0+005A (A-Z) MUST be considered equivalent to U+0061 through U+007A (a-z). The field contents can contain any UTF-8 character. +

+
+
+

+各フィールドは、AN =文字で区切られたフィールド名とフィールドの内容で構成されています。フィールド名は、U+003Dを除くUTF-8コードポイントU+0020からU+007Eからのみで構成されている必要があります。これは=文字です。言い換えれば、フィールド名には、Equals Signを除くすべての印刷可能なASCII文字を含めることができます。フィールド名の評価は症例ではないため、U+0041から0+005A（A-Z）は、U+0061からU+007A（A-Z）に相当すると見なす必要があります。フィールドの内容には、任意のUTF-8文字を含めることができます。 +

+
+
+
+
+

+Note that the Vorbis comment as used in Vorbis allows for 2^64 bytes of data whereas the FLAC metadata block is limited to 2^24 bytes. Given the stated purpose of Vorbis comments, i.e., human-readable textual information, the FLAC metadata block limit is unlikely to be restrictive. Also, note that the 32-bit field lengths are coded little-endian as opposed to the usual big-endian coding of fixed-length integers in the rest of the FLAC format. +

+
+
+

+Vorbisで使用されているVorbisコメントは、2^64バイトのデータを許可するのに対し、FLACメタデータブロックは2^24バイトに制限されていることに注意してください。Vorbisのコメントの記載されている目的、つまり人間の読み取り可能なテキスト情報を考えると、FLACメタデータブロックの制限は制限されそうにありません。また、32ビットのフィールド長は、FLAC形式の残りの部分での固定整数の通常のビッグエンディアンコーディングとは対照的に、小さなエンディアンとコード化されていることに注意してください。 +

+
+
+
+
+
+8.6.1. Standard Field Names +
+
+
+
+8.6.1. 標準フィールド名 +
+
+
+
+
+

+Only one standard field name is defined: the channel mask field (see Section 8.6.2). No other field names are defined because the applicability of any field name is strongly tied to the content it is associated with. For example, field names that are useful for describing files that contain a single work of music would be unusable when labeling archived broadcasts, recordings of any kind, or a collection of music works. Even when describing a single work of music, different conventions exist depending on the kind of music: orchestral music differs from music by solo artists or bands. +

+
+
+

+定義されている標準フィールド名は1つだけです。チャネルマスクフィールド（セクション8.6.2を参照）。フィールド名の適用性が関連付けられているコンテンツに強く結び付けられているため、他のフィールド名は定義されていません。たとえば、アーカイブブロードキャスト、あらゆる種類の録音、音楽のコレクションにラベルを付ける場合、音楽の単一の作品を含むファイルを説明するのに役立つフィールド名は使用できません。音楽の単一の作品を説明するときでさえ、音楽の種類に応じて異なるコンベンションが存在します。オーケストラの音楽は、ソロアーティストやバンドの音楽とは異なります。 +

+
+
+
+
+

+Despite the fact that no field names are formally defined, there is a general trend among devices and software capable of FLAC playback that are meant to play music. Most of those recognize at least the following field names: +

+
+
+

+正式に定義されているフィールド名はないという事実にもかかわらず、音楽を再生することを目的としたFLAC再生が可能なデバイスやソフトウェアの間に一般的な傾向があります。それらのほとんどは、少なくとも次のフィールド名を認識しています。 +

+
+
+
+
+

+Title: +

+
+
+

+タイトル： +

+
+
+
+
+

+Name of the current work. +

+
+
+

+現在の作業の名前。 +

+
+
+
+
+

+Artist: +

+
+
+

+アーティスト： +

+
+
+
+
+

+Name of the artist generally responsible for the current work. For orchestral works, this is usually the composer; otherwise, it is often the performer. +

+
+
+

+一般的に現在の作品を担当するアーティストの名前。オーケストラの作品にとって、これは通常作曲家です。そうでなければ、それはしばしばパフォーマーです。 +

+
+
+
+
+

+Album: +

+
+
+

+アルバム： +

+
+
+
+
+

+Name of the collection the current work belongs to. +

+
+
+

+現在の作品が属するコレクションの名前。 +

+
+
+
+
+

+For a more comprehensive list of possible field names suited for describing a single work of music in various genres, the list of tags used in the MusicBrainz project is suggested; see [MusicBrainz]. +

+
+
+

+さまざまなジャンルで音楽の単一の作品を説明するのに適したフィールド名のより包括的なリストのリストについては、MusicBrainzプロジェクトで使用されるタグのリストが提案されています。[MusicBrainz]を参照してください。 +

+
+
+
+
+
+8.6.2. Channel Mask +
+
+
+
+8.6.2. チャンネルマスク +
+
+
+
+
+

+Besides fields containing information about the work itself, one field is defined for technical reasons: WAVEFORMATEXTENSIBLE_CHANNEL_MASK. This field is used to communicate that the channels in a file differ from the default channels defined in Section 9.1.3. For example, by default, a FLAC file containing two channels is interpreted to contain a left and right channel, but with this field, it is possible to describe different channel contents. +

+
+
+

+作業自体に関する情報を含むフィールドに加えて、1つのフィールドは、技術的な理由で定義されています：waveformatextensible_channel_mask。このフィールドは、ファイル内のチャネルがセクション9.1.3で定義されているデフォルトチャネルと異なることを通信するために使用されます。たとえば、デフォルトでは、2つのチャネルを含むFLACファイルが左右のチャネルが含まれていると解釈されますが、このフィールドでは、異なるチャネルの内容を記述することができます。 +

+
+
+
+
+

+The channel mask consists of flag bits indicating which channels are present. The flags only signal which channels are present, not in which order, so if a file to be encoded has channels that are ordered differently, they have to be reordered. This mask is stored with a hexadecimal representation preceded by 0x; see the examples below. Please note that a file in which the channel order is defined through the WAVEFORMATEXTENSIBLE_CHANNEL_MASK is not streamable (see Section 7), as the field is not found in each frame header. The mask bits can be found in the following table. +

+
+
+

+チャネルマスクは、どのチャネルが存在するかを示すフラグビットで構成されています。フラグは、どのチャネルが存在するかのみの信号のみであり、どの順序ではないため、エンコードされるファイルに異なる方法で注文されるチャネルがある場合、それらを再注文する必要があります。このマスクは、0xが先行する16進表現で保存されています。以下の例を参照してください。各フレームヘッダーにフィールドが見つからないため、チャネル順序がwaveformatextensible_channel_maskを介して定義されるファイル（セクション7を参照）に注意してください。マスクビットは次の表にあります。 +

+
+
+
+
+ 
+                        +============+=============================+
+                        | Bit Number | Channel Description         |
+                        +============+=============================+
+                        | 0          | Front left                  |
+                        +------------+-----------------------------+
+                        | 1          | Front right                 |
+                        +------------+-----------------------------+
+                        | 2          | Front center                |
+                        +------------+-----------------------------+
+                        | 3          | Low-frequency effects (LFE) |
+                        +------------+-----------------------------+
+                        | 4          | Back left                   |
+                        +------------+-----------------------------+
+                        | 5          | Back right                  |
+                        +------------+-----------------------------+
+                        | 6          | Front left of center        |
+                        +------------+-----------------------------+
+                        | 7          | Front right of center       |
+                        +------------+-----------------------------+
+                        | 8          | Back center                 |
+                        +------------+-----------------------------+
+                        | 9          | Side left                   |
+                        +------------+-----------------------------+
+                        | 10         | Side right                  |
+                        +------------+-----------------------------+
+                        | 11         | Top center                  |
+                        +------------+-----------------------------+
+                        | 12         | Top front left              |
+                        +------------+-----------------------------+
+                        | 13         | Top front center            |
+                        +------------+-----------------------------+
+                        | 14         | Top front right             |
+                        +------------+-----------------------------+
+                        | 15         | Top rear left               |
+                        +------------+-----------------------------+
+                        | 16         | Top rear center             |
+                        +------------+-----------------------------+
+                        | 17         | Top rear right              |
+                        +------------+-----------------------------+
+
+                                          Table 8
+
+
+
+
+
+

+Following are three examples: +

+
+
+

+以下は3つの例です。 +

+
+
+
+
+

+* A file has a single channel -- an LFE channel. The Vorbis comment field is WAVEFORMATEXTENSIBLE_CHANNEL_MASK=0x8. +

+
+
+

+* ファイルには、LFEチャネルという単一のチャネルがあります。Vorbisのコメントフィールドはwaveformatextensible_channel_mask = 0x8です。 +

+
+
+
+
+

+* A file has four channels -- front left, front right, top front left, and top front right. The Vorbis comment field is WAVEFORMATEXTENSIBLE_CHANNEL_MASK=0x5003. +

+
+
+

+* ファイルには4つのチャネルがあります。左前面、前面、左上、左上、右上右上部。Vorbisのコメントフィールドは波形xtensible_channel_mask = 0x5003です。 +

+
+
+
+
+

+* An input has four channels -- back center, top front center, front center, and top rear center in that order. These have to be reordered to front center, back center, top front center, and top rear center. The Vorbis comment field added is WAVEFORMATEXTENSIBLE_CHANNEL_MASK=0x12104. +

+
+
+

+* 入力には、その順序でバックセンター、トップフロントセンター、フロントセンター、トップリアセンターの4つのチャネルがあります。これらは、フロントセンター、バックセンター、トップフロントセンター、トップリアセンターに並べ替える必要があります。追加されたVorbisのコメントフィールドは、waveformatextensible_channel_mask = 0x12104です。 +

+
+
+
+
+

+WAVEFORMATEXTENSIBLE_CHANNEL_MASK fields MAY be padded with zeros, for example, 0x0008 for a single LFE channel. Parsing of WAVEFORMATEXTENSIBLE_CHANNEL_MASK fields MUST be case-insensitive for both the field name and the field contents. +

+
+
+

+WaveFormateXtensible_Channel_Maskフィールドには、単一のLFEチャネルで0x0008など、ゼロがパッドで埋められている場合があります。WaveFormateXtensible_Channel_Maskフィールドの解析は、フィールド名とフィールドの内容の両方でケース非感受性でなければなりません。 +

+
+
+
+
+

+A WAVEFORMATEXTENSIBLE_CHANNEL_MASK field of 0x0 can be used to indicate that none of the audio channels of a file correlate with speaker positions. This is the case when audio needs to be decoded into speaker positions (e.g., Ambisonics B-format audio) or when a multitrack recording is contained. +

+
+
+

+0x0の波形Xtensible_channel_maskフィールドを使用して、ファイルのオーディオチャネルがスピーカーの位置と相関していないことを示すことができます。これは、オーディオをスピーカーの位置にデコードする必要がある場合（たとえば、Ambisonics B-Format Audio）、またはマルチトラックの録音が含まれている場合です。 +

+
+
+
+
+

+It is possible for a WAVEFORMATEXTENSIBLE_CHANNEL_MASK field to code for fewer channels than are present in the audio. If that is the case, the remaining channels SHOULD NOT be rendered by a playback application unfamiliar with their purpose. For example, the Ambisonics UHJ format is compatible with stereo playback: its first two channels can be played back on stereo equipment, but all four channels together can be decoded into surround sound. For that example, the Vorbis comment field WAVEFORMATEXTENSIBLE_CHANNEL_MASK=0x3 would be set, indicating that the first two channels are front left and front right and other channels do not correlate with speaker positions directly. +

+
+
+

+波形Xtensible_Channel_Maskフィールドが、音声に存在するよりも少ないチャネルをコードすることができます。その場合、残りのチャネルは、目的に不慣れな再生アプリケーションによってレンダリングされるべきではありません。たとえば、Ambisonics UHJ形式はステレオ再生と互換性があります。最初の2つのチャネルはステレオ機器で再生できますが、4つのチャネルはすべて一緒にサラウンドサウンドにデコードできます。その例では、Vorbisのコメントフィールドwaveformatextensible_channel_mask = 0x3が設定され、最初の2つのチャネルが左前面と正面右であり、他のチャネルがスピーカーの位置と直接相関しないことを示します。 +

+
+
+
+
+

+If audio channels not assigned to any speaker are contained and decoding to speaker positions is possible, it is recommended to provide metadata on how this decoding should take place in another Vorbis comment field or an application metadata block. This document does not define such metadata. +

+
+
+

+スピーカーに割り当てられていないオーディオチャネルが含まれており、スピーカーの位置にデコードすることが可能な場合は、別のVorbisコメントフィールドまたはアプリケーションメタデータブロックでこのデコードがどのように行われるかについてメタデータを提供することをお勧めします。このドキュメントは、そのようなメタデータを定義しません。 +

+
+
+
+
+
+8.7. Cuesheet +
+
+
+
+8.7. キューシート +
+
+
+
+
+

+A cuesheet metadata block can be used either to store the track and index point structure of a Compact Disc Digital Audio (CD-DA) along with its audio or to provide a mechanism to store locations of interest within a FLAC file. Certain aspects of this metadata block come directly from the CD-DA specification (called Red Book), which is standardized as [IEC.60908.1999]. The description below is complete, and further reference to [IEC.60908.1999] is not needed to implement this metadata block. +

+
+
+

+キューシートメタデータブロックを使用して、コンパクトディスクデジタルオーディオ（CD-DA）のトラックおよびインデックスポイント構造をオーディオとともに保存するか、FLACファイル内に関心のある場所を保存するメカニズムを提供することができます。このメタデータブロックの特定の側面は、[IEC.60908.1999]として標準化されているCD-DA仕様（Red Bookと呼ばれる）から直接届きます。以下の説明は完全であり、このメタデータブロックを実装するために[IEC.60908.1999]へのさらなる参照は必要ありません。 +

+
+
+
+
+

+The structure of a cuesheet metadata block is enumerated in the following table. +

+
+
+

+キューシートメタデータブロックの構造は、次の表に列挙されています。 +

+
+
+
+
+ 
++============+======================================================+
+| Data       | Description                                          |
++============+======================================================+
+| u(128*8)   | Media catalog number in ASCII                        |
+|            | printable characters 0x20-0x7E.                      |
++------------+------------------------------------------------------+
+| u(64)      | Number of lead-in samples.                           |
++------------+------------------------------------------------------+
+| u(1)       | 1 if the cuesheet corresponds to a                   |
+|            | CD-DA; else 0.                                       |
++------------+------------------------------------------------------+
+| u(7+258*8) | Reserved.  All bits MUST be set to                   |
+|            | zero.                                                |
++------------+------------------------------------------------------+
+| u(8)       | Number of tracks in this cuesheet.                   |
++------------+------------------------------------------------------+
+| Cuesheet   | A number of structures as specified                  |
+| tracks     | in Section 8.7.1 equal to the number                 |
+|            | of tracks specified previously.                      |
++------------+------------------------------------------------------+
+
+                               Table 9
+
+
+
+
+
+

+If the media catalog number is less than 128 bytes long, it is right-padded with 0x00 bytes. For CD-DA, this is a 13-digit number followed by 115 0x00 bytes. +

+
+
+

+メディアカタログ番号の長さが128バイト未満の場合、0x00バイトで右パッドが付いています。CD-DAの場合、これは13桁の数字に続いて115 0x00バイトです。 +

+
+
+
+
+

+The number of lead-in samples has meaning only for CD-DA cuesheets; for other uses, it should be 0. For CD-DA, the lead-in is the TRACK 00 area where the table of contents is stored; more precisely, it is the number of samples from the first sample of the media to the first sample of the first index point of the first track. According to [IEC.60908.1999], the lead-in MUST be silent, and CD grabbing software does not usually store it; additionally, the lead-in MUST be at least two seconds but MAY be longer. For these reasons, the lead-in length is stored here so that the absolute position of the first track can be computed. Note that the lead-in stored here is the number of samples up to the first index point of the first track, not necessarily to INDEX 01 of the first track; even the first track MAY have INDEX 00 data. +

+
+
+

+リードインサンプルの数は、CD-DAキューシートのみを意味します。他の用途の場合、それは0でなければなりません。CD-DAの場合、リードインは目次が保存されているトラック00エリアです。より正確には、メディアの最初のサンプルから最初のトラックの最初のインデックスポイントの最初のサンプルまでのサンプルの数です。[IEC.60908.1999]によれば、リードインは沈黙している必要があり、CDグラブするソフトウェアは通常保存しません。さらに、リードインは少なくとも2秒でなければなりませんが、長くなる必要があります。これらの理由により、最初のトラックの絶対位置を計算できるように、リードインの長さがここに保存されます。ここに保存されているリードインは、最初のトラックの最初のトラックの最初のインデックスポイントまでのサンプルの数であり、必ずしも最初のトラックの01インデックスではありません。最初のトラックでさえ、インデックス00データがある場合があります。 +

+
+
+
+
+

+The number of tracks MUST be at least 1, as a cuesheet block MUST have a lead-out track. For CD-DA, this number MUST be no more than 100 (99 regular tracks and one lead-out track). The lead-out track is always the last track in the cuesheet. For CD-DA, the lead-out track number MUST be 170 as specified by [IEC.60908.1999]; otherwise, it MUST be 255. +

+
+
+

+キューシートブロックにはリードアウトトラックが必要なため、トラックの数は少なくとも1でなければなりません。CD-DAの場合、この数値は100（99の通常のトラックと1つのリードアウトトラック）を超えている必要があります。リードアウトトラックは、常にキューシートの最後のトラックです。CD-DAの場合、[IEC.60908.1999]で指定されているように、リードアウトトラック番号は170でなければなりません。それ以外の場合は、255でなければなりません。 +

+
+
+
+
+
+8.7.1. Cuesheet Track +
+
+
+
+8.7.1. キューシートトラック +
+
+
+
+
+ 
++=============+=====================================================+
+| Data        | Description                                         |
++=============+=====================================================+
+| u(64)       | Track offset of the first index point in            |
+|             | samples, relative to the beginning of the           |
+|             | FLAC audio stream.                                  |
++-------------+-----------------------------------------------------+
+| u(8)        | Track number.                                       |
++-------------+-----------------------------------------------------+
+| u(12*8)     | Track ISRC.                                         |
++-------------+-----------------------------------------------------+
+| u(1)        | The track type: 0 for audio, 1 for non-audio.       |
+|             | This corresponds to the CD-DA Q-channel             |
+|             | control bit 3.                                      |
++-------------+-----------------------------------------------------+
+| u(1)        | The pre-emphasis flag: 0 for no pre-emphasis,       |
+|             | 1 for pre-emphasis.  This corresponds to the        |
+|             | CD-DA Q-channel control bit 5.                      |
++-------------+-----------------------------------------------------+
+| u(6+13*8)   | Reserved.  All bits MUST be set to zero.            |
++-------------+-----------------------------------------------------+
+| u(8)        | The number of track index points.                   |
++-------------+-----------------------------------------------------+
+| Cuesheet    | For all tracks except the lead-out track, a         |
+| track index | number of structures as specified in                |
+| points      | Section 8.7.1.1 equal to the number of index        |
+|             | points specified previously.                        |
++-------------+-----------------------------------------------------+
+
+                               Table 10
+
+
+
+
+
+

+Note that the track offset differs from the one in CD-DA, where the track's offset in the table of contents (TOC) is that of the track's INDEX 01 even if there is an INDEX 00. For CD-DA, the track offset MUST be evenly divisible by 588 samples (588 samples = 44100 samples/ s * 1/75 s). +

+
+
+

+トラックオフセットはCD-DAのものとは異なります。このテーブル（TOC）におけるトラックのオフセットは、インデックス00がある場合でもトラックのインデックス01のものです。CD-DAの場合、トラックオフセットは必要です588サンプル（588サンプル= 44100サンプル/ s * 1/75秒）で均等に分裂します。 +

+
+
+
+
+

+A track number of 0 is not allowed because the CD-DA specification reserves this for the lead-in. For CD-DA, the number MUST be 1-99 or 170 for the lead-out; for non-CD-DA, the track number MUST be 255 for the lead-out. It is recommended to start with track 1 and increase sequentially. Track numbers MUST be unique within a cuesheet. +

+
+
+

+CD-DA仕様がリードイン用にこれを予約するため、トラック番号0は許可されていません。CD-DAの場合、リードアウトの場合、数は1-99または170でなければなりません。非CD-DAの場合、トラック番号はリードアウトの場合は255でなければなりません。トラック1から開始し、順次増加することをお勧めします。トラック番号は、キューシート内で一意でなければなりません。 +

+
+
+
+
+

+The track ISRC (International Standard Recording Code) is a 12-digit alphanumeric code; see [ISRC-handbook]. A value of 12 ASCII 0x00 characters MAY be used to denote the absence of an ISRC. +

+
+
+

+トラックISRC（International Standard Recording Code）は、12桁の英数字コードです。[ISRCハンドブック]を参照してください。12個のASCII 0x00文字の値を使用して、ISRCの欠如を示すことができます。 +

+
+
+
+
+

+There MUST be at least one index point in every track in a cuesheet except for the lead-out track, which MUST have zero. For CD-DA, the number of index points MUST NOT be more than 100. +

+
+
+

+キューシートのすべてのトラックには、リードアウトトラックを除いて、ゼロが必要なものがないことを除いて、少なくとも1つのインデックスポイントが必要です。CD-DAの場合、インデックスポイントの数は100を超えてはなりません。 +

+
+
+
+
+
+8.7.1.1. Cuesheet Track Index Point +
+
+
+
+8.7.1.1. Cuesheetトラックインデックスポイント +
+
+
+
+
+ 
+                      +========+====================================+
+                      | Data   | Description                        |
+                      +========+====================================+
+                      | u(64)  | Offset in samples, relative to the |
+                      |        | track offset, of the index point.  |
+                      +--------+------------------------------------+
+                      | u(8)   | The track index point number.      |
+                      +--------+------------------------------------+
+                      | u(3*8) | Reserved.  All bits MUST be set to |
+                      |        | zero.                              |
+                      +--------+------------------------------------+
+
+                                          Table 11
+
+
+
+
+
+

+For CD-DA, the track index point offset MUST be evenly divisible by 588 samples (588 samples = 44100 samples/s * 1/75 s). Note that the offset is from the beginning of the track, not the beginning of the audio data. +

+
+
+

+CD-DAの場合、トラックインデックスポイントオフセットは588サンプル（588サンプル= 44100サンプル/s * 1/75秒）で均等に分割できる必要があります。オフセットは、オーディオデータの開始ではなく、トラックの開始からのものであることに注意してください。 +

+
+
+
+
+

+For CD-DA, a track index point number of 0 corresponds to the track pre-gap. The first index point in a track MUST have a number of 0 or 1, and subsequently, index point numbers MUST increase by 1. Index point numbers MUST be unique within a track. +

+
+
+

+CD-DAの場合、トラックインデックスポイント番号0は、トラックのプレギャップに対応します。トラックの最初のインデックスポイントには0または1が多数ある必要があり、その後、インデックスポイント番号が1増加する必要があります。インデックスポイント番号はトラック内で一意でなければなりません。 +

+
+
+
+
+
+8.8. Picture +
+
+
+
+8.8. 写真 +
+
+
+
+
+

+The picture metadata block contains image data of a picture in some way belonging to the audio contained in the FLAC file. Its format is derived from the Attached Picture (APIC) frame in the ID3v2 specification; see [ID3v2]. However, contrary to the APIC frame in ID3v2, the media type and description are prepended with a 4-byte length field instead of being 0x00 delimited strings. A FLAC file MAY contain one or more picture metadata blocks. +

+
+
+

+画像メタデータブロックには、FLACファイルに含まれるオーディオに属する何らかの方法で、画像の画像データが含まれています。その形式は、ID3v2仕様の添付画像（APIC）フレームから派生しています。[id3v2]を参照してください。ただし、ID3v2のAPICフレームとは反対に、メディアタイプと説明は、0x00の区切り文字列ではなく、4バイトの長さフィールドで準備されています。FLACファイルには、1つ以上の画像メタデータブロックが含まれる場合があります。 +

+
+
+
+
+

+Note that while the length fields for media type, description, and picture data are 4 bytes in length and could code for a size up to 4 GiB in theory, the total metadata block size cannot exceed what can be described by the metadata block header, i.e., 16 MiB. +

+
+
+

+メディアタイプ、説明、および画像データの長さフィールドの長さは4バイトで、理論的には最大4ギブのサイズをコーディングできますが、メタデータブロックサイズの合計はメタデータブロックヘッダーで説明できるものを超えることはできないことに注意してください。すなわち、16ミブ。 +

+
+
+
+
+

+Instead of picture data, the picture metadata block can also contain a URI as described in [RFC3986]. +

+
+
+

+画像データの代わりに、[RFC3986]に記載されているように、画像メタデータブロックにもURIを含めることができます。 +

+
+
+
+
+

+The structure of a picture metadata block is enumerated in the following table. +

+
+
+

+画像メタデータブロックの構造は、次の表に列挙されています。 +

+
+
+
+
+ 
++========+==========================================================+
+| Data   | Description                                              |
++========+==========================================================+
+| u(32)  | The picture type according to Table 13.                  |
++--------+----------------------------------------------------------+
+| u(32)  | The length of the media type string in bytes.            |
++--------+----------------------------------------------------------+
+| u(n*8) | The media type string as specified by [RFC2046],         |
+|        | or the text string --> to signify that the data          |
+|        | part is a URI of the picture instead of the              |
+|        | picture data itself.  This field must be in              |
+|        | printable ASCII characters 0x20-0x7E.                    |
++--------+----------------------------------------------------------+
+| u(32)  | The length of the description string in bytes.           |
++--------+----------------------------------------------------------+
+| u(n*8) | The description of the picture in UTF-8.                 |
++--------+----------------------------------------------------------+
+| u(32)  | The width of the picture in pixels.                      |
++--------+----------------------------------------------------------+
+| u(32)  | The height of the picture in pixels.                     |
++--------+----------------------------------------------------------+
+| u(32)  | The color depth of the picture in bits per               |
+|        | pixel.                                                   |
++--------+----------------------------------------------------------+
+| u(32)  | For indexed-color pictures (e.g., GIF), the              |
+|        | number of colors used; 0 for non-indexed                 |
+|        | pictures.                                                |
++--------+----------------------------------------------------------+
+| u(32)  | The length of the picture data in bytes.                 |
++--------+----------------------------------------------------------+
+| u(n*8) | The binary picture data.                                 |
++--------+----------------------------------------------------------+
+
+                               Table 12
+
+
+
+
+
+

+The height, width, color depth, and "number of colors" fields are for informational purposes only. Applications MUST NOT use them in decoding the picture or deciding how to display it, but applications MAY use them to decide whether or not to process a block (e.g., when selecting between different picture blocks) and MAY show them to the user. If a picture has no concept for any of these fields (e.g., vector images may not have a height or width in pixels) or the content of any field is unknown, the affected fields MUST be set to zero. +

+
+
+

+高さ、幅、色の深さ、「色の数」フィールドは、情報目的のみを目的としています。アプリケーションは、画像のデコードや表示方法の決定にそれらを使用してはなりませんが、アプリケーションはそれらを使用してブロックを処理するかどうか（例：異なる画像ブロック間を選択するとき）を決定し、ユーザーに表示する場合があります。これらのフィールドのいずれかの概念がない場合（たとえば、ベクトル画像にピクセルで高さや幅がない場合があります）、または任意のフィールドの内容が不明である場合、影響を受けるフィールドはゼロに設定する必要があります。 +

+
+
+
+
+

+The following table contains all the defined picture types. Values other than those listed in the table are reserved. There MAY only be one each of picture types 1 and 2 in a file. In general practice, many FLAC playback devices and software display the contents of a picture metadata block, if present, with picture type 3 (front cover) during playback. +

+
+
+

+次の表には、定義されたすべての画像タイプが含まれています。テーブルにリストされている値以外の値は予約されています。ファイルには、それぞれの画像タイプ1と2のみが1つしかありません。一般的には、多くのFLAC再生デバイスとソフトウェアが、再生中に画像タイプ3（フロントカバー）を備えた画像メタデータブロックの内容を表示します。 +

+
+
+
+
+ 
+          +=======+=================================================+
+          | Value | Picture Type                                    |
+          +=======+=================================================+
+          | 0     | Other                                           |
+          +-------+-------------------------------------------------+
+          | 1     | PNG file icon of 32x32 pixels (see [RFC2083])   |
+          +-------+-------------------------------------------------+
+          | 2     | General file icon                               |
+          +-------+-------------------------------------------------+
+          | 3     | Front cover                                     |
+          +-------+-------------------------------------------------+
+          | 4     | Back cover                                      |
+          +-------+-------------------------------------------------+
+          | 5     | Liner notes page                                |
+          +-------+-------------------------------------------------+
+          | 6     | Media label (e.g., CD, Vinyl or Cassette label) |
+          +-------+-------------------------------------------------+
+          | 7     | Lead artist, lead performer, or soloist         |
+          +-------+-------------------------------------------------+
+          | 8     | Artist or performer                             |
+          +-------+-------------------------------------------------+
+          | 9     | Conductor                                       |
+          +-------+-------------------------------------------------+
+          | 10    | Band or orchestra                               |
+          +-------+-------------------------------------------------+
+          | 11    | Composer                                        |
+          +-------+-------------------------------------------------+
+          | 12    | Lyricist or text writer                         |
+          +-------+-------------------------------------------------+
+          | 13    | Recording location                              |
+          +-------+-------------------------------------------------+
+          | 14    | During recording                                |
+          +-------+-------------------------------------------------+
+          | 15    | During performance                              |
+          +-------+-------------------------------------------------+
+          | 16    | Movie or video screen capture                   |
+          +-------+-------------------------------------------------+
+          | 17    | A bright colored fish                           |
+          +-------+-------------------------------------------------+
+          | 18    | Illustration                                    |
+          +-------+-------------------------------------------------+
+          | 19    | Band or artist logotype                         |
+          +-------+-------------------------------------------------+
+          | 20    | Publisher or studio logotype                    |
+          +-------+-------------------------------------------------+
+
+                                    Table 13
+
+
+
+
+
+

+The origin and use of value 17 ("A bright colored fish") is unclear. This was copied to maintain compatibility with ID3v2. Applications are discouraged from offering this value to users when embedding a picture. +

+
+
+

+値17（「明るい色の魚」）の起源と使用は不明です。これは、ID3v2との互換性を維持するためにコピーされました。アプリケーションは、写真を埋め込むときにユーザーにこの価値を提供することを思いとどまらせます。 +

+
+
+
+
+

+If a URI (not a picture) is contained in this block, the following points apply: +

+
+
+

+このブロックにURI（写真ではない）が含まれている場合、次のポイントが適用されます。 +

+
+
+
+
+

+* The URI can be in either absolute or relative form. If a URI is in relative form, it is related to the URI of the FLAC content processed. +

+
+
+

+* URIは、絶対的または相対的な形式になります。URIが相対的な形である場合、それは処理されたFLAC含有量のURIに関連しています。 +

+
+
+
+
+

+* Applications MUST obtain explicit user approval to retrieve images via remote protocols and to retrieve local images that are not located in the same directory as the FLAC file being processed. +

+
+
+

+* アプリケーションは、リモートプロトコルを介して画像を取得し、処理されているFLACファイルと同じディレクトリにないローカル画像を取得するために、明示的なユーザー承認を取得する必要があります。 +

+
+
+
+
+

+* Applications supporting linked images MUST handle unavailability of URIs gracefully. They MAY report unavailability to the user. +

+
+
+

+* リンクされた画像をサポートするアプリケーションは、URIの不可能性を優雅に処理する必要があります。ユーザーに利用不能を報告する場合があります。 +

+
+
+
+
+

+* Applications MAY reject processing URIs for any reason, particularly for security or privacy reasons. +

+
+
+

+* アプリケーションは、特にセキュリティまたはプライバシーの理由により、何らかの理由でURIの処理を拒否する場合があります。 +

+
+
+
+
+
+9. Frame Structure +
+
+
+
+9. フレーム構造 +
+
+
+
+
+

+One or more frames follow directly after the last metadata block. Each frame consists of a frame header, one or more subframes, padding zero bits to achieve byte alignment, and a frame footer. The number of subframes in each frame is equal to the number of audio channels. +

+
+
+

+最後のメタデータブロックの直後に1つ以上のフレームが続きます。各フレームは、フレームヘッダー、1つ以上のサブフレーム、バイトアライメントを実現するためにゼロビットをパディングする、およびフレームフッターで構成されています。各フレームのサブフレームの数は、オーディオチャネルの数に等しくなります。 +

+
+
+
+
+

+Each frame header stores the audio sample rate, number of bits per sample, and number of channels independently of the streaminfo metadata block and other frame headers. This was done to permit multicasting of FLAC files, but it also allows these properties to change mid-stream. Because not all environments in which FLAC decoders are used are able to cope with changes to these properties during playback, a decoder MAY choose to stop decoding on such a change. A decoder that does not check for such a change could be vulnerable to buffer overflows. See also Section 11. +

+
+
+

+各フレームヘッダーは、オーディオサンプルレート、サンプルあたりのビット数、およびStreaminfoメタデータブロックおよびその他のフレームヘッダーとは無関係にチャネルの数を保存します。これは、FLACファイルのマルチキャストを許可するために行われましたが、これらのプロパティが中間ストリームを変更することもできます。FLACデコーダーが使用されるすべての環境が再生中にこれらのプロパティの変更に対処できるわけではないため、デコーダーはそのような変更のデコードを停止することを選択できます。このような変更をチェックしないデコーダーは、バッファーオーバーフローに対して脆弱です。セクション11も参照してください。 +

+
+
+
+
+

+Note that storing audio with changing audio properties in FLAC results in various practical problems. For example, these changes of audio properties must happen on a frame boundary or the process will not be lossless. When a variable block size is chosen to accommodate this, note that blocks smaller than 16 samples are not allowed; therefore, it is not possible to store an audio stream in which these properties change within 16 samples of the last change or the start of the file. Also, since the streaminfo metadata block can only accommodate a single set of properties, it is only valid for part of such an audio stream. Instead, it is RECOMMENDED to store an audio stream with changing properties in FLAC encapsulated in a container capable of handling such changes, as these do not suffer from the mentioned limitations. See Section 10 for details. +

+
+
+

+FLACのオーディオプロパティの変更でオーディオを保存すると、さまざまな実際的な問題が発生することに注意してください。たとえば、これらのオーディオプロパティの変更は、フレームの境界で発生する必要があります。または、プロセスがロスレスではありません。これに対応するために可変ブロックサイズが選択されている場合、16個未満のサンプルが許可されていないことに注意してください。したがって、これらのプロパティが最後の変更またはファイルの開始の16サンプル内で変更されるオーディオストリームを保存することはできません。また、Streaminfoメタデータブロックは単一のプロパティのみにのみ対応できるため、このようなオーディオストリームの一部にのみ有効です。代わりに、このような変更を処理できるコンテナにカプセル化されたFLACのプロパティの変更を伴うオーディオストリームを保存することをお勧めします。詳細については、セクション10を参照してください。 +

+
+
+
+
+
+9.1. Frame Header +
+
+
+
+9.1. フレームヘッダー +
+
+
+
+
+

+Each frame MUST start on a byte boundary and start with the 15-bit frame sync code 0b111111111111100. Following the sync code is the blocking strategy bit, which MUST NOT change during the audio stream. The blocking strategy bit is 0 for a fixed block size stream or 1 for a variable block size stream. If the blocking strategy is known, a decoder can include this bit when searching for the start of a frame to reduce the possibility of encountering a false positive, as the first two bytes of a frame are either 0xFFF8 for a fixed block size stream or 0xFFF9 for a variable block size stream. +

+
+
+

+各フレームはバイト境界で開始し、15ビットフレーム同期コード0B111111111111100から開始する必要があります。同期コードに従うことは、ブロッキング戦略ビットです。これは、オーディオストリーム中に変更してはなりません。ブロッキング戦略ビットは、固定ブロックサイズのストリームの場合は0、可変ブロックサイズストリームの場合は1です。ブロッキング戦略がわかっている場合、デコーダーはフレームの開始を検索するときにこのビットを含めることができます。フレームの最初の2バイトは固定ブロックサイズストリームの0xfff8または0xfff9のいずれかであるため、可変ブロックサイズのストリームの場合。 +

+
+
+
+
+
+9.1.1. Block Size Bits +
+
+
+
+9.1.1. ブロックサイズビット +
+
+
+
+
+

+Following the frame sync code and blocking strategy bit are 4 bits (the first 4 bits of the third byte of each frame) referred to as the block size bits. Their value relates to the block size according to the following table, where v is the value of the 4 bits as an unsigned number. If the block size bits code for an uncommon block size, this is stored after the coded number; see Section 9.1.6. +

+
+
+

+フレームの同期コードとブロッキング戦略ビットに続くのは、ブロックサイズビットと呼ばれる4ビット（各フレームの3番目のバイトの最初の4ビット）です。それらの値は、次の表に従ってブロックサイズに関連しています。ここで、Vは署名されていない数値として4ビットの値です。ブロックサイズが珍しいブロックサイズのコードをビットする場合、これはコード化された数字の後に保存されます。セクション9.1.6を参照してください。 +

+
+
+
+
+ 
+    +=================+=============================================+
+    | Value           | Block Size                                  |
+    +=================+=============================================+
+    | 0b0000          | Reserved                                    |
+    +-----------------+---------------------------------------------+
+    | 0b0001          | 192                                         |
+    +-----------------+---------------------------------------------+
+    | 0b0010 - 0b0101 | 144 * (2^v), i.e., 576, 1152, 2304, or 4608 |
+    +-----------------+---------------------------------------------+
+    | 0b0110          | Uncommon block size minus 1, stored as an   |
+    |                 | 8-bit number                                |
+    +-----------------+---------------------------------------------+
+    | 0b0111          | Uncommon block size minus 1, stored as a    |
+    |                 | 16-bit number                               |
+    +-----------------+---------------------------------------------+
+    | 0b1000 - 0b1111 | 2^v, i.e., 256, 512, 1024, 2048, 4096,      |
+    |                 | 8192, 16384, or 32768                       |
+    +-----------------+---------------------------------------------+
+
+                                 Table 14
+
+
+
+
+
+
+9.1.2. Sample Rate Bits +
+
+
+
+9.1.2. サンプルレートビット +
+
+
+
+
+

+The next 4 bits (the last 4 bits of the third byte of each frame), referred to as the sample rate bits, contain the sample rate of the audio according to the following table. If the sample rate bits code for an uncommon sample rate, this is stored after the uncommon block size; if no uncommon block size was used, this is stored after the coded number. See Section 9.1.7. +

+
+
+

+サンプルレートビットと呼ばれる次の4ビット（各フレームの3番目のバイトの最後の4ビット）には、次の表に従ってオーディオのサンプルレートが含まれています。If the sample rate bits code for an uncommon sample rate, this is stored after the uncommon block size;if no uncommon block size was used, this is stored after the coded number.See Section 9.1.7. +

+
+
+
+
+ 
++========+==========================================================+
+| Value  | Sample Rate                                              |
++========+==========================================================+
+| 0b0000 | Sample rate only stored in the                           |
+|        | streaminfo metadata block                                |
++--------+----------------------------------------------------------+
+| 0b0001 | 88.2 kHz                                                 |
++--------+----------------------------------------------------------+
+| 0b0010 | 176.4 kHz                                                |
++--------+----------------------------------------------------------+
+| 0b0011 | 192 kHz                                                  |
++--------+----------------------------------------------------------+
+| 0b0100 | 8 kHz                                                    |
++--------+----------------------------------------------------------+
+| 0b0101 | 16 kHz                                                   |
++--------+----------------------------------------------------------+
+| 0b0110 | 22.05 kHz                                                |
++--------+----------------------------------------------------------+
+| 0b0111 | 24 kHz                                                   |
++--------+----------------------------------------------------------+
+| 0b1000 | 32 kHz                                                   |
++--------+----------------------------------------------------------+
+| 0b1001 | 44.1 kHz                                                 |
++--------+----------------------------------------------------------+
+| 0b1010 | 48 kHz                                                   |
++--------+----------------------------------------------------------+
+| 0b1011 | 96 kHz                                                   |
++--------+----------------------------------------------------------+
+| 0b1100 | Uncommon sample rate in kHz,                             |
+|        | stored as an 8-bit number                                |
++--------+----------------------------------------------------------+
+| 0b1101 | Uncommon sample rate in Hz, stored                       |
+|        | as a 16-bit number                                       |
++--------+----------------------------------------------------------+
+| 0b1110 | Uncommon sample rate in Hz divided                       |
+|        | by 10, stored as a 16-bit number                         |
++--------+----------------------------------------------------------+
+| 0b1111 | Forbidden                                                |
++--------+----------------------------------------------------------+
+
+                               Table 15
+
+
+
+
+
+
+9.1.3. Channels Bits +
+
+
+
+9.1.3. チャンネルビット +
+
+
+
+
+

+The next 4 bits (the first 4 bits of the fourth byte of each frame), referred to as the channels bits, contain both the number of channels of the audio as well as any stereo decorrelation used according to the following table. +

+
+
+

+次の4ビット（各フレームの4番目のバイトの最初の4ビット）は、チャンネルビットと呼ばれ、オーディオのチャネル数と、次の表に従って使用されるステレオ除去の両方を含む。 +

+
+
+
+
+

+If a channel layout different than the ones listed in the following table is used, this can be signaled with a WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag in a Vorbis comment metadata block; see Section 8.6.2 for details. Note that even when such a different channel layout is specified with a WAVEFORMATEXTENSIBLE_CHANNEL_MASK and the channel ordering in the following table is overridden, the channels bits still contain the actual number of channels coded in the frame. For details on the way left-side, side-right, and mid-side stereo are coded, see Section 4.2. +

+
+
+

+次の表にリストされているものとは異なるチャネルレイアウトが使用される場合、これはVorbisコメントメタデータブロックに波形Xtensible_Channel_Maskタグで信号を送ることができます。詳細については、セクション8.6.2を参照してください。このような異なるチャネルレイアウトがWaveformatextensible_Channel_Maskで指定されている場合でも、次の表のチャネルの順序付けがオーバーライドされている場合、チャネルビットにはフレームにコードされた実際の数のチャネル数が含まれています。左サイド、サイドライト、およびミッドサイドのステレオの方法の詳細については、セクション4.2を参照してください。 +

+
+
+
+
+ 
+    +==========+====================================================+
+    | Value    | Channels                                           |
+    +==========+====================================================+
+    | 0b0000   | 1 channel: mono                                    |
+    +----------+----------------------------------------------------+
+    | 0b0001   | 2 channels: left, right                            |
+    +----------+----------------------------------------------------+
+    | 0b0010   | 3 channels: left, right, center                    |
+    +----------+----------------------------------------------------+
+    | 0b0011   | 4 channels: front left, front right, back left,    |
+    |          | back right                                         |
+    +----------+----------------------------------------------------+
+    | 0b0100   | 5 channels: front left, front right, front center, |
+    |          | back/surround left, back/surround right            |
+    +----------+----------------------------------------------------+
+    | 0b0101   | 6 channels: front left, front right, front center, |
+    |          | LFE, back/surround left, back/surround right       |
+    +----------+----------------------------------------------------+
+    | 0b0110   | 7 channels: front left, front right, front center, |
+    |          | LFE, back center, side left, side right            |
+    +----------+----------------------------------------------------+
+    | 0b0111   | 8 channels: front left, front right, front center, |
+    |          | LFE, back left, back right, side left, side right  |
+    +----------+----------------------------------------------------+
+    | 0b1000   | 2 channels: left, right; stored as left-side       |
+    |          | stereo                                             |
+    +----------+----------------------------------------------------+
+    | 0b1001   | 2 channels: left, right; stored as side-right      |
+    |          | stereo                                             |
+    +----------+----------------------------------------------------+
+    | 0b1010   | 2 channels: left, right; stored as mid-side stereo |
+    +----------+----------------------------------------------------+
+    | 0b1011 - | Reserved                                           |
+    | 0b1111   |                                                    |
+    +----------+----------------------------------------------------+
+
+                                 Table 16
+
+
+
+
+
+
+9.1.4. Bit Depth Bits +
+
+
+
+9.1.4. ビット深度ビット +
+
+
+
+
+

+The next 3 bits (bits 5, 6, and 7 of each fourth byte of each frame) contain the bit depth of the audio according to the following table. The next bit is reserved and MUST be zero. +

+
+
+

+次の3ビット（各フレームの各4バイトのビット5、6、および7）には、次の表に従ってオーディオのビット深さが含まれています。次のビットは予約されており、ゼロでなければなりません。 +

+
+
+
+
+ 
+  +=======+========================================================+
+  | Value | Bit Depth                                              |
+  +=======+========================================================+
+  | 0b000 | Bit depth only stored in the streaminfo metadata block |
+  +-------+--------------------------------------------------------+
+  | 0b001 | 8 bits per sample                                      |
+  +-------+--------------------------------------------------------+
+  | 0b010 | 12 bits per sample                                     |
+  +-------+--------------------------------------------------------+
+  | 0b011 | Reserved                                               |
+  +-------+--------------------------------------------------------+
+  | 0b100 | 16 bits per sample                                     |
+  +-------+--------------------------------------------------------+
+  | 0b101 | 20 bits per sample                                     |
+  +-------+--------------------------------------------------------+
+  | 0b110 | 24 bits per sample                                     |
+  +-------+--------------------------------------------------------+
+  | 0b111 | 32 bits per sample                                     |
+  +-------+--------------------------------------------------------+
+
+                               Table 17
+
+
+
+
+
+
+9.1.5. Coded Number +
+
+
+
+9.1.5. コード化された番号 +
+
+
+
+
+

+Following the reserved bit (starting at the fifth byte of the frame) is either a sample or a frame number, which will be referred to as the coded number. When dealing with variable block size streams, the sample number of the first sample in the frame is encoded. When the file contains a fixed block size stream, the frame number is encoded. See Section 9.1 on the blocking strategy bit, which signals whether a stream is a fixed block size stream or a variable block size stream. See also Appendix B.1. +

+
+
+

+予約されたビット（フレームの5番目のバイトから始まる）に続くのは、サンプルまたはフレーム番号のいずれかで、コード化された番号と呼ばれます。可変ブロックサイズのストリームを扱うとき、フレーム内の最初のサンプルのサンプル番号がエンコードされます。ファイルに固定ブロックサイズのストリームが含まれている場合、フレーム番号がエンコードされます。ブロッキング戦略ビットのセクション9.1を参照してください。これは、ストリームが固定ブロックサイズのストリームであるか、可変ブロックサイズのストリームであるかを示すものです。付録B.1も参照してください。 +

+
+
+
+
+

+The coded number is stored in a variable-length code like UTF-8 as defined in [RFC3629] but extended to a maximum of 36 bits unencoded or 7 bytes encoded. +

+
+
+

+コード化された数値は、[RFC3629]で定義されているようにUTF-8のような可変長コードに保存されますが、エンコードされていない最大36ビットまたはエンコードされた7バイトに拡張されます。 +

+
+
+
+
+

+When a frame number is encoded, the value MUST NOT be larger than what fits a value of 31 bits unencoded or 6 bytes encoded. Please note that as most general purpose UTF-8 encoders and decoders follow [RFC3629], they will not be able to handle these extended codes. Furthermore, while UTF-8 is specifically used to encode characters, FLAC uses it to encode numbers instead. To encode or decode a coded number, follow the procedures in Section 3 of [RFC3629], but instead of using a character number, use a frame or sample number. In addition, use the extended table below instead of the table in Section 3 of [RFC3629]. +

+
+
+

+フレーム番号がエンコードされている場合、値は、エンコードされていない31ビットまたはエンコードされた6バイトの値よりも大きくてはなりません。ほとんどの汎用目的UTF-8エンコーダーとデコーダーが続くため[RFC3629]、これらの拡張コードを処理できないことに注意してください。さらに、UTF-8は特に文字をエンコードするために使用されますが、FLACは代わりに数値をエンコードするために使用します。コード化された番号をエンコードまたはデコードするには、[RFC3629]のセクション3の手順に従ってください。ただし、文字番号を使用する代わりに、フレームまたはサンプル番号を使用します。さらに、[RFC3629]のセクション3の表の代わりに、下の拡張テーブルを使用します。 +

+
+
+
+
+ 
++============================+=====================================+
+| Number Range (Hexadecimal) | Octet Sequence (Binary)             |
++============================+=====================================+
+| 0000 0000 0000 -           | 0xxxxxxx                            |
+| 0000 0000 007F             |                                     |
++----------------------------+-------------------------------------+
+| 0000 0000 0080 -           | 110xxxxx 10xxxxxx                   |
+| 0000 0000 07FF             |                                     |
++----------------------------+-------------------------------------+
+| 0000 0000 0800 -           | 1110xxxx 10xxxxxx 10xxxxxx          |
+| 0000 0000 FFFF             |                                     |
++----------------------------+-------------------------------------+
+| 0000 0001 0000 -           | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx |
+| 0000 001F FFFF             |                                     |
++----------------------------+-------------------------------------+
+| 0000 0020 0000 -           | 111110xx 10xxxxxx 10xxxxxx 10xxxxxx |
+| 0000 03FF FFFF             | 10xxxxxx                            |
++----------------------------+-------------------------------------+
+| 0000 0400 0000 -           | 1111110x 10xxxxxx 10xxxxxx 10xxxxxx |
+| 0000 7FFF FFFF             | 10xxxxxx 10xxxxxx                   |
++----------------------------+-------------------------------------+
+| 0000 8000 0000 -           | 11111110 10xxxxxx 10xxxxxx 10xxxxxx |
+| 000F FFFF FFFF             | 10xxxxxx 10xxxxxx 10xxxxxx          |
++----------------------------+-------------------------------------+
+
+                              Table 18
+
+
+
+
+
+

+If the coded number is a frame number, it MUST be equal to the number of frames preceding the current frame. If the coded number is a sample number, it MUST be equal to the number of samples preceding the current frame. In a stream where these requirements are not met, seeking is not (reliably) possible. +

+
+
+

+コード化された番号がフレーム番号の場合、現在のフレームの前のフレームの数に等しくなければなりません。コード化された数値がサンプル番号の場合、現在のフレームの前のサンプルの数に等しくなければなりません。これらの要件が満たされないストリームでは、求めることは（確実に）不可能です。 +

+
+
+
+
+

+For example, for a frame that belongs to a variable block size stream and has exactly 51 billion samples preceding it, the coded number is constructed as follows: +

+
+
+

+たとえば、可変ブロックサイズのストリームに属し、その先に510億のサンプルがあるフレームの場合、コード化された数値は次のように構築されます。 +

+
+
+
+
+ 
+   Octets 1-5
+   0b11111110 0b10101111 0b10011111 0b10110101 0b10100011
+                  ^^^^^^     ^^^^^^     ^^^^^^     ^^^^^^
+                    |          |          |      Bits 18-13
+                    |          |      Bits 24-19
+                    |      Bits 30-25
+                Bits 36-31
+
+   Octets 6-7
+   0b10111000 0b10000000
+       ^^^^^^     ^^^^^^
+         |       Bits 6-1
+     Bits 12-7
+
+
+
+
+
+

+A decoder that relies on the coded number during seeking could be vulnerable to buffer overflows or getting stuck in an infinite loop if it seeks in a stream where the coded numbers are not strictly increasing or are otherwise not valid. See also Section 11. +

+
+
+

+シーク中にコード化された数値に依存するデコーダーは、コード化された数値が厳密に増加していないか、そうでなければ有効でないストリームで探す場合、バッファーオーバーフローや無限のループに詰まっていることに対して脆弱である可能性があります。セクション11も参照してください。 +

+
+
+
+
+
+9.1.6. Uncommon Block Size +
+
+
+
+9.1.6. まれなブロックサイズ +
+
+
+
+
+

+If the block size bits defined earlier in this section are 0b0110 or 0b0111 (uncommon block size minus 1 stored), the block size minus 1 follows the coded number as either an 8-bit or 16-bit unsigned number coded big-endian. A value of 65535 (corresponding to a block size of 65536) is forbidden and MUST NOT be used, because such a block size cannot be represented in the streaminfo metadata block. A value from 0 up to (and including) 14, which corresponds to a block size from 1 to 15, is only valid for the last frame in a stream and MUST NOT be used for any other frame. See also Section 8.2. +

+
+
+

+このセクションの前半に定義されたブロックサイズビットが0B0110または0B0111（除外されていない未知のブロックサイズマイナス1保存）の場合、ブロックサイズマイナス1は、コード化された数を8ビットまたは16ビットの符号なしの数字コード化されたビッグエンディアンとして追跡します。65535の値（65536のブロックサイズに対応）は禁止されており、そのようなブロックサイズをStreaminfoメタデータブロックで表すことができないため、使用してはなりません。1から15までのブロックサイズに対応する0から（および含む）14から14までの値は、ストリーム内の最後のフレームに対してのみ有効であり、他のフレームには使用してはなりません。セクション8.2も参照してください。 +

+
+
+
+
+
+9.1.7. Uncommon Sample Rate +
+
+
+
+9.1.7. まれなサンプルレート +
+
+
+
+
+

+If the sample rate bits are 0b1100, 0b1101, or 0b1110 (uncommon sample rate stored), the sample rate follows the uncommon block size (or the coded number if no uncommon block size is stored) as either an 8-bit or a 16-bit unsigned number coded big-endian. +

+
+
+

+サンプルレートビットが0B1100、0B1101、または0B1110（サンプルレートを格納していない）の場合、サンプルレートは、8ビットまたは16-のいずれかとして、CONCOMMONブロックサイズがない場合はコード化された数値を使用していない場合）に従います。ビット署名数字コード化されたビッグエンディアン。 +

+
+
+
+
+

+The sample rate MUST NOT be 0 when the subframe contains audio. A sample rate of 0 MAY be used when non-audio is represented. See Section 8.2 for details. +

+
+
+

+サブフレームにオーディオが含まれている場合、サンプルレートは0ではありません。非オーディオが表される場合、0のサンプルレートを使用できます。詳細については、セクション8.2を参照してください。 +

+
+
+
+
+
+9.1.8. Frame Header CRC +
+
+
+
+9.1.8. フレームヘッダーCRC +
+
+
+
+
+

+Finally, an 8-bit CRC follows the frame/sample number, an uncommon block size, or an uncommon sample rate (depending on whether the latter two are stored). This CRC is initialized with 0 and has the polynomial x^8 + x^2 + x^1 + x^0. This CRC covers the whole frame header before the CRC, including the sync code. +

+
+
+

+最後に、8ビットCRCは、フレーム/サンプル番号、珍しいブロックサイズ、または珍しいサンプルレートに従います（後者の2つが保存されているかどうかに応じて）。このCRCは0で初期化され、多項式x^8 + x^2 + x^1 + x^0があります。このCRCは、同期コードを含むCRCの前にフレームヘッダー全体をカバーします。 +

+
+
+
+
+
+9.2. Subframes +
+
+
+
+9.2. サブフレーム +
+
+
+
+
+

+Following the frame header are a number of subframes equal to the number of audio channels. Note that subframes contain a bitstream that does not necessarily have to be a whole number of bytes, so only the first subframe starts at a byte boundary. +

+
+
+

+フレームヘッダーに従うことは、オーディオチャネルの数に等しい多数のサブフレームがあります。サブフレームには、必ずしもすべてのバイトである必要はないビットストリームが含まれているため、最初のサブフレームのみがバイト境界で始まることに注意してください。 +

+
+
+
+
+
+9.2.1. Subframe Header +
+
+
+
+9.2.1. サブフレームヘッダー +
+
+
+
+
+

+Each subframe starts with a header. The first bit of the header MUST be 0, followed by 6 bits that describe which subframe type is used according to the following table, where v is the value of the 6 bits as an unsigned number. +

+
+
+

+各サブフレームはヘッダーから始まります。ヘッダーの最初のビットは0でなければなりません。その後、次の表に従って使用されるサブフレームタイプを説明する6ビットが続きます。ここで、vは6ビットの値が符号なし数として値です。 +

+
+
+
+
+ 
+  +=====================+===========================================+
+  | Value               | Subframe Type                             |
+  +=====================+===========================================+
+  | 0b000000            | Constant subframe                         |
+  +---------------------+-------------------------------------------+
+  | 0b000001            | Verbatim subframe                         |
+  +---------------------+-------------------------------------------+
+  | 0b000010 - 0b000111 | Reserved                                  |
+  +---------------------+-------------------------------------------+
+  | 0b001000 - 0b001100 | Subframe with a fixed predictor of order  |
+  |                     | v-8; i.e., 0, 1, 2, 3 or 4                |
+  +---------------------+-------------------------------------------+
+  | 0b001101 - 0b011111 | Reserved                                  |
+  +---------------------+-------------------------------------------+
+  | 0b100000 - 0b111111 | Subframe with a linear predictor of order |
+  |                     | v-31; i.e., 1 through 32 (inclusive)      |
+  +---------------------+-------------------------------------------+
+
+                                Table 19
+
+
+
+
+
+

+Following the subframe type bits is a bit that flags whether the subframe uses any wasted bits (see Section 9.2.2). If the flag bit is 0, the subframe doesn't use any wasted bits and the subframe header is complete. If the flag bit is 1, the subframe uses wasted bits and the number of used wasted bits minus 1 appears in unary form, directly following the flag bit. +

+
+
+

+サブフレームタイプのビットに従うことは、サブフレームが無駄なビットを使用するかどうかにフラグを立てることに少しです（セクション9.2.2を参照）。フラグビットが0の場合、サブフレームは無駄なビットを使用せず、サブフレームヘッダーが完了します。フラグビットが1の場合、サブフレームは無駄なビットを使用し、使用済みビットマイナス1の数は、フラグビットに直接続く統一形式で表示されます。 +

+
+
+
+
+
+9.2.2. Wasted Bits per Sample +
+
+
+
+9.2.2. サンプルごとに無駄なビット +
+
+
+
+
+

+Most uncompressed audio file formats can only store audio samples with a bit depth that is an integer number of bytes. Samples in which the bit depth is not an integer number of bytes are usually stored in such formats by padding them with least-significant zero bits to a bit depth that is an integer number of bytes. For example, shifting a 14-bit sample right by 2 pads it to a 16-bit sample, which then has two zero least-significant bits. In this specification, these least-significant zero bits are referred to as wasted bits per sample or simply wasted bits. They are wasted in the sense that they contain no information but are stored anyway. +

+
+
+

+ほとんどの非圧縮オーディオファイル形式は、整数のバイト数である少し深さでオーディオサンプルのみを保存できます。ビット深度が整数数のバイト数ではないサンプルは、通常、整数ゼロビットで整数の深さであるバイト数であるビット深度にパディングすることにより、そのような形式で保存されます。たとえば、14ビットのサンプルを2倍にシフトすると、16ビットのサンプルにパッドを配置し、2つの最小重要なビットがあります。この仕様では、これらの最も重要でないゼロビットは、サンプルごとに無駄なビットまたは単に無駄なビットと呼ばれます。彼らは情報を含んでいないがとにかく保存されているという意味で無駄になります。 +

+
+
+
+
+

+The FLAC format can optionally take advantage of these wasted bits by signaling their presence and coding the subframe without them. To do this, the wasted bits per sample flag in a subframe header is set to 1 and the number of wasted bits per sample (k) minus 1 follows the flag in an unary encoding. For example, if k is 3, 0b001 follows. If k = 0, the wasted bits per sample flag is 0 and no unary-coded k follows. In this document, if a subframe header signals a certain number of wasted bits, it is said it "uses" these wasted bits. +

+
+
+

+FLAC形式は、オプションでこれらの無駄なビットを利用して、それらの存在を通知し、サブフレームを使用せずにコーディングすることにより、これらの無駄なビットを利用できます。これを行うために、サブフレームヘッダーのサンプルフラグごとの無駄なビットは1に設定され、サンプルあたりの無駄なビット数（k）マイナス1は、単位エンコードでフラグに続きます。たとえば、Kが3の場合、0B001が続きます。k = 0の場合、サンプルフラグごとに無駄なビットが0であり、unary-coded kは続きません。このドキュメントでは、サブフレームヘッダーが一定数の無駄なビットを信号する場合、これらの無駄なビットを「使用」すると言われています。 +

+
+
+
+
+

+If a subframe uses wasted bits (i.e., k is not equal to 0), samples are coded ignoring k least-significant bits. For example, if a frame not employing stereo decorrelation specifies a sample size of 16 bits per sample in the frame header and k of a subframe is 3, samples in the subframe are coded as 13 bits per sample. For more details, see Section 9.2.3 on how the bit depth of a subframe is calculated. A decoder MUST add k least-significant zero bits by shifting left (padding) after decoding a subframe sample. If the frame has left-side, side-right, or mid-side stereo, a decoder MUST perform padding on the subframes before restoring the channels to left and right. The number of wasted bits per sample MUST be such that the resulting number of bits per sample (of which the calculation is explained in Section 9.2.3) is larger than zero. +

+
+
+

+サブフレームが無駄なビットを使用している場合（つまり、Kは0に等しくない）、サンプルはKの最も重要なビットを無視してコード化されます。たとえば、ステレオ脱線を使用していないフレームがフレームヘッダーのサンプルあたり16ビットのサンプルサイズを指定し、サブフレームのKのKが3の場合、サブフレームのサンプルはサンプルごとに13ビットとしてコーディングされます。詳細については、サブフレームのビット深さの計算方法については、セクション9.2.3を参照してください。デコーダーは、サブフレームサンプルをデコードした後、左（パディング）をシフトすることにより、Kの最小重要なゼロビットを追加する必要があります。フレームに左側、側面、または中央のステレオがある場合、デコーダーはチャネルを左右に復元する前にサブフレームでパディングを実行する必要があります。サンプルあたりの無駄なビット数は、サンプルあたりのビット数（セクション9.2.3で説明されている）がゼロよりも大きいようにする必要があります。 +

+
+
+
+
+

+Besides audio files that have a certain number of wasted bits for the whole file, audio files exist in which the number of wasted bits varies. There are DVD-Audio discs in which blocks of samples have had their least-significant bits selectively zeroed to slightly improve the compression of their otherwise lossless Meridian Lossless Packing codec; see [MLP]. There are also audio processors like lossyWAV (see [lossyWAV]) that zero a number of least-significant bits for a block of samples, increasing the compression in a non-lossless way. Because of this, the number of wasted bits k MAY change between frames and MAY differ between subframes. If the number of wasted bits changes halfway through a subframe (e.g., the first part has 2 wasted bits and the second part has 4 wasted bits), the subframe uses the lowest number of wasted bits; otherwise, non-zero bits would be discarded, and the process would not be lossless. +

+
+
+

+ファイル全体に一定数の無駄なビットを持つオーディオファイルに加えて、無駄なビットの数が異なるオーディオファイルが存在します。サンプルのブロックが最も重要でないビットを選択的にゼロにして、それ以外の場合は損失のない子午線ロスレスパッキングコーデックの圧縮をわずかに改善するDVD-Audioディスクがあります。[MLP]を参照してください。また、サンプルのブロックで最も重要な少ないビットをゼロでゼロで、損失のない方法で圧縮を増加させる、losywav（[losywav]を参照）などのオーディオプロセッサもあります。このため、無駄なビットkの数はフレーム間で変化し、サブフレーム間で異なる場合があります。無駄なビットの数がサブフレームの途中で変化する場合（たとえば、最初の部分には2つの無駄なビットがあり、2番目の部分には4つのビットが4つあります）、サブフレームは無駄なビットの数が最も少ないです。そうしないと、ゼロ以外のビットが破棄され、プロセスはロスレスになりません。 +

+
+
+
+
+
+9.2.3. Constant Subframe +
+
+
+
+9.2.3. 定数サブフレーム +
+
+
+
+
+

+In a constant subframe, only a single sample is stored. This sample is stored as an integer number coded big-endian, signed two's complement. The number of bits used to store this sample depends on the bit depth of the current subframe. The bit depth of a subframe is equal to the bit depth as coded in the frame header (see Section 9.1.4) minus the number of used wasted bits coded in the subframe header (see Section 9.2.2). If a subframe is a side subframe (see Section 4.2), the bit depth of that subframe is increased by 1 bit. +

+
+
+

+一定のサブフレームでは、1つのサンプルのみが保存されます。このサンプルは、ビッグエンディアンのコード化された整数番号として保存され、2人の補完に署名されています。このサンプルを保存するために使用されるビットの数は、現在のサブフレームのビット深度に依存します。サブフレームのビット深度は、フレームヘッダーでコード化されたビット深度に等しくなります（セクション9.1.4を参照）は、サブフレームヘッダーでコード化された使用された無駄なビットの数を差し引いて（セクション9.2.2を参照）。サブフレームがサイドサブフレームである場合（セクション4.2を参照）、そのサブフレームのビット深度は1ビット増加します。 +

+
+
+
+
+
+9.2.4. Verbatim Subframe +
+
+
+
+9.2.4. Verbatimサブフレーム +
+
+
+
+
+

+A verbatim subframe stores all samples unencoded in sequential order. See Section 9.2.3 on how a sample is stored unencoded. The number of samples that need to be stored in a subframe is provided by the block size in the frame header. +

+
+
+

+逐語的なサブフレームは、順次順序でエンコードされていないすべてのサンプルを保存します。サンプルがエンコードされていない保管方法については、セクション9.2.3を参照してください。サブフレームに保存する必要があるサンプルの数は、フレームヘッダーのブロックサイズによって提供されます。 +

+
+
+
+
+
+9.2.5. Fixed Predictor Subframe +
+
+
+
+9.2.5. 予測子サブフレームを修正しました +
+
+
+
+
+

+Five different fixed predictors are defined in the following table, one for each prediction order 0 through 4. The table also contains a derivation that explains the rationale for choosing these fixed predictors. +

+
+
+

+次の表には、5つの異なる固定予測子が定義されています。1つは予測順序0〜4です。表には、これらの固定予測因子を選択する理論的根拠を説明する派生も含まれています。 +

+
+
+
+
+ 
+  +=======+==================================+======================+
+  | Order | Prediction                       | Derivation           |
+  +=======+==================================+======================+
+  | 0     | 0                                | N/A                  |
+  +-------+----------------------------------+----------------------+
+  | 1     | a(n-1)                           | N/A                  |
+  +-------+----------------------------------+----------------------+
+  | 2     | 2 * a(n-1) - a(n-2)              | a(n-1) + a'(n-1)     |
+  +-------+----------------------------------+----------------------+
+  | 3     | 3 * a(n-1) - 3 * a(n-2) + a(n-3) | a(n-1) + a'(n-1) +   |
+  |       |                                  | a''(n-1)             |
+  +-------+----------------------------------+----------------------+
+  | 4     | 4 * a(n-1) - 6 * a(n-2) + 4 *    | a(n-1) + a'(n-1) +   |
+  |       | a(n-3) - a(n-4)                  | a''(n-1) + a'''(n-1) |
+  +-------+----------------------------------+----------------------+
+
+                                Table 20
+
+
+
+
+
+

+Where: +

+
+
+

+ただし： +

+
+
+
+
+

+* n is the number of the sample being predicted. +

+
+
+

+* nは予測されるサンプルの数です。 +

+
+
+
+
+

+* a(n) is the sample being predicted. +

+
+
+

+* A（n）は予測されるサンプルです。 +

+
+
+
+
+

+* a(n-1) is the sample before the one being predicted. +

+
+
+

+* A（n-1）は、予測される前のサンプルです。 +

+
+
+
+
+

+* a'(n-1) is the difference between the previous sample and the sample before that, i.e., a(n-1) - a(n-2). This is the closest available first-order discrete derivative. +

+
+
+

+* a '（n-1）は、前のサンプルとその前のサンプルの違い、すなわちa（n-1）-a（n-2）です。これは、最も近い1次離散微分です。 +

+
+
+
+
+

+* a''(n-1) is a'(n-1) - a'(n-2) or the closest available second-order discrete derivative. +

+
+
+

+* a ''（n-1）はa '（n-1） - a'（n-2）または最も近い2次離散微分です。 +

+
+
+
+
+

+* a'''(n-1) is a''(n-1) - a''(n-2) or the closest available third-order discrete derivative. +

+
+
+

+* a '' '（n-1）はa' '（n-1）-a' '（n-2）または最も近い3次離散微分です。 +

+
+
+
+
+

+As a predictor makes use of samples preceding the sample that is predicted, it can only be used when enough samples are known. As each subframe in FLAC is coded completely independently, the first few samples in each subframe cannot be predicted. Therefore, a number of so-called warm-up samples equal to the predictor order is stored. These are stored unencoded, bypassing the predictor and residual coding stages. See Section 9.2.3 on how samples are stored unencoded. The table below defines how a fixed predictor subframe appears in the bitstream. +

+
+
+

+予測子は、予測されるサンプルの前のサンプルを使用するため、十分なサンプルがわかっている場合にのみ使用できます。FLACの各サブフレームは完全に独立してコーディングされるため、各サブフレームの最初の数サンプルは予測できません。したがって、予測順に等しいいわゆるウォームアップサンプルが保存されます。これらは、予測因子と残留コーディング段階をバイパスして、エンコードされていない保存されます。サンプルがエンコードされていない保管方法については、セクション9.2.3を参照してください。以下の表は、BitStreamに固定予測サブフレームがどのように表示されるかを定義しています。 +

+
+
+
+
+ 
+            +==========+===========================================+
+            | Data     | Description                               |
+            +==========+===========================================+
+            | s(n)     | Unencoded warm-up samples (n = subframe's |
+            |          | bits per sample * predictor order).       |
+            +----------+-------------------------------------------+
+            | Coded    | Coded residual as defined in              |
+            | residual | Section 9.2.7                             |
+            +----------+-------------------------------------------+
+
+                                    Table 21
+
+
+
+
+
+

+Because fixed predictors are specified, they do not have to be stored. The fixed predictor order, which is stored in the subframe header, specifies which predictor is used. +

+
+
+

+固定予測子が指定されているため、保存する必要はありません。サブフレームヘッダーに保存されている固定予測順序は、どの予測子が使用されるかを指定します。 +

+
+
+
+
+

+To encode a signal with a fixed predictor, each sample has the corresponding prediction subtracted and sent to the residual coder. To decode a signal with a fixed predictor, the residual is decoded, and then the prediction can be added for each sample. This means that decoding is necessarily a sequential process within a subframe, as for each sample, enough fully decoded previous samples are needed to calculate the prediction. +

+
+
+

+固定予測子を使用して信号をエンコードするために、各サンプルには対応する予測が差し引かれ、残差コーダーに送信されます。固定予測子で信号をデコードするために、残差がデコードされ、各サンプルに予測を追加できます。つまり、デコードは必然的にサブフレーム内の連続プロセスであり、各サンプルと同様に、予測を計算するのに十分な完全にデコードされた以前のサンプルが必要であることを意味します。 +

+
+
+
+
+

+For fixed predictor order 0, the prediction is always 0; thus, each residual sample is equal to its corresponding input or decoded sample. The difference between a fixed predictor with order 0 and a verbatim subframe is that a verbatim subframe stores all samples unencoded while a fixed predictor with order 0 has all its samples processed by the residual coder. +

+
+
+

+固定された予測因子順序0の場合、予測は常に0です。したがって、各残差サンプルは、対応する入力またはデコードされたサンプルに等しくなります。順序0の固定予測子と逐語的なサブフレームの違いは、逐語的なサブフレームがすべてのサンプルをエンコードされていないすべてのサンプルを保存し、注文0の固定予測子にはすべてのサンプルが残差コーダーによって処理されていることです。 +

+
+
+
+
+

+The first-order fixed predictor is comparable to how differential pulse-code modulation (DPCM) encoding works, as the resulting residual sample is the difference between the corresponding sample and the sample before it. The higher-order fixed predictors can be understood as polynomials fitted to the previous samples. +

+
+
+

+一次固定予測子は、結果の残差サンプルが対応するサンプルとその前のサンプルの違いであるため、微分パルスコード変調（DPCM）エンコーディングがどのように機能するかに匹敵します。高次の固定予測因子は、以前のサンプルに適合した多項式として理解できます。 +

+
+
+
+
+
+9.2.6. Linear Predictor Subframe +
+
+
+
+9.2.6. 線形予測サブフレーム +
+
+
+
+
+

+Whereas fixed predictors are well suited for simple signals, using a (non-fixed) linear predictor on more complex signals can improve compression by making the residual samples even smaller. There is a certain trade-off, however, as storing the predictor coefficients takes up space as well. +

+
+
+

+一方、固定された予測因子は単純な信号に適していますが、より複雑な信号に（固定されていない）線形予測因子を使用すると、残差サンプルをさらに小さくすることで圧縮を改善できます。ただし、予測係数を保存することもスペースを占めるため、特定のトレードオフがあります。 +

+
+
+
+
+

+In the FLAC format, a predictor is defined by up to 32 predictor coefficients and a shift. To form a prediction, each coefficient is multiplied by its corresponding past sample, the results are summed, and this sum is then shifted. To encode a signal with a linear predictor, each sample has the corresponding prediction subtracted and sent to the residual coder. To decode a signal with a linear predictor, the residual is decoded, and then the prediction can be added for each sample. This means that decoding MUST be a sequential process within a subframe, as enough decoded samples are needed to calculate the prediction for each sample. +

+
+
+

+FLAC形式では、予測子は最大32の予測係数とシフトによって定義されます。予測を形成するために、各係数に対応する過去のサンプルを掛け、結果が合計され、この合計がシフトされます。線形予測子を使用して信号をエンコードするために、各サンプルには対応する予測が減算され、残差コーダーに送信されます。線形予測因子で信号をデコードするために、残差がデコードされ、各サンプルに予測を追加できます。つまり、各サンプルの予測を計算するのに十分なデコードされたサンプルが必要であるため、デコードはサブフレーム内の順次プロセスでなければなりません。 +

+
+
+
+
+

+The table below defines how a linear predictor subframe appears in the bitstream. +

+
+
+

+以下の表は、ビットストリームに線形予測サブフレームがどのように表示されるかを定義しています。 +

+
+
+
+
+ 
+              +==========+==========================================+
+              | Data     | Description                              |
+              +==========+==========================================+
+              | s(n)     | Unencoded warm-up samples (n =           |
+              |          | subframe's bits per sample * LPC order). |
+              +----------+------------------------------------------+
+              | u(4)     | (Predictor coefficient precision in      |
+              |          | bits)-1 (Note: 0b1111 is forbidden).     |
+              +----------+------------------------------------------+
+              | s(5)     | Prediction right shift needed in bits.   |
+              +----------+------------------------------------------+
+              | s(n)     | Predictor coefficients (n = predictor    |
+              |          | coefficient precision * LPC order).      |
+              +----------+------------------------------------------+
+              | Coded    | Coded residual as defined in             |
+              | residual | Section 9.2.7.                           |
+              +----------+------------------------------------------+
+
+                                      Table 22
+
+
+
+
+
+

+See Section 9.2.3 on how the warm-up samples are stored unencoded. The predictor coefficients are stored as an integer number coded big-endian, signed two's complement, where the number of bits needed for each coefficient is defined by the predictor coefficient precision. While the prediction right shift is signed two's complement, this number MUST NOT be negative; see Appendix B.4 for an explanation why this is. +

+
+
+

+ウォームアップサンプルがエンコードされていない保管方法については、セクション9.2.3を参照してください。予測係数は、各係数に必要なビット数が予測係数精度によって定義される2つの補数に署名された2つの補数に署名された整数の補体された整数数として保存されます。予測の正しいシフトはTwoの補完に署名されていますが、この数は否定的であってはなりません。これがなぜであるかについては、付録B.4を参照してください。 +

+
+
+
+
+

+Please note that the order in which the predictor coefficients appear in the bitstream corresponds to which *past* sample they belong to. In other words, the order of the predictor coefficients is opposite to the chronological order of the samples. So, the first predictor coefficient has to be multiplied with the sample directly before the sample that is being predicted, the second predictor coefficient has to be multiplied with the sample before that, etc. +

+
+
+

+ビットストリームに予測係数が表示される順序は、それらが属している *過去 *サンプルに対応することに注意してください。言い換えれば、予測係数の順序は、サンプルの時系列の順序とは反対です。したがって、最初の予測係数は、予測されるサンプルの直前にサンプルとの直前に、2番目の予測係数をその前にサンプルに乗算する必要があります。 +

+
+
+
+
+
+9.2.7. Coded Residual +
+
+
+
+9.2.7. コード化された残差 +
+
+
+
+
+

+The first two bits in a coded residual indicate which coding method is used. See the table below. +

+
+
+

+コード化された残差の最初の2つのビットは、どのコーディング方法が使用されているかを示します。以下の表を参照してください。 +

+
+
+
+
+ 
+        +=============+=============================================+
+        | Value       | Description                                 |
+        +=============+=============================================+
+        | 0b00        | Partitioned Rice code with 4-bit parameters |
+        +-------------+---------------------------------------------+
+        | 0b01        | Partitioned Rice code with 5-bit parameters |
+        +-------------+---------------------------------------------+
+        | 0b10 - 0b11 | Reserved                                    |
+        +-------------+---------------------------------------------+
+
+                                   Table 23
+
+
+
+
+
+

+Both defined coding methods work the same way but differ in the number of bits used for Rice parameters. The 4 bits that directly follow the coding method bits form the partition order, which is an unsigned number. The rest of the coded residual consists of 2^(partition order) partitions. For example, if the 4 bits are 0b1000, the partition order is 8, and the residual is split up into 2^8 = 256 partitions. +

+
+
+

+両方の定義されたコーディングメソッドは同じように機能しますが、イネパラメーターに使用されるビットの数が異なります。コーディングメソッドビットに直接続く4ビットは、パーティション順序を形成します。これは署名されていない数字です。コード化された残りの残りの部分は、2^（パーティションの順序）パーティションで構成されています。たとえば、4ビットが0B1000の場合、パーティション順序は8で、残差は2^8 = 256パーティションに分割されます。 +

+
+
+
+
+

+Each partition contains a certain number of residual samples. The number of residual samples in the first partition is equal to (block size >> partition order) - predictor order, i.e., the block size divided by the number of partitions minus the predictor order. In all other partitions, the number of residual samples is equal to (block size >> partition order). +

+
+
+

+各パーティションには、一定数の残差サンプルが含まれています。最初のパーティションの残差サンプルの数は、（ブロックサイズ>>パーティション順序） - 予測順、つまり、ブロックサイズをパーティションの数を差し引いて予測順に除算します。他のすべてのパーティションでは、残差サンプルの数は（ブロックサイズ>>パーティション順序）に等しくなります。 +

+
+
+
+
+

+The partition order MUST be such that the block size is evenly divisible by the number of partitions. This means, for example, that only partition order 0 is allowed for all odd block sizes. The partition order also MUST be such that the (block size >> partition order) is larger than the predictor order. This means, for example, that with a block size of 4096 and a predictor order of 4, the partition order cannot be larger than 9. +

+
+
+

+パーティションの順序は、ブロックサイズがパーティションの数によって均等に分裂できるようにする必要があります。これは、たとえば、すべての奇数ブロックサイズでパーティション順序0のみが許可されることを意味します。パーティション順序は、（ブロックサイズ>>パーティション順序）が予測順に大きくなるようなものでなければなりません。これは、たとえば、ブロックサイズが4096で、予測因子順序が4の場合、パーティションの順序が9を超えることはできないことを意味します。 +

+
+
+
+
+

+Each partition starts with a parameter. If the coded residual of a subframe is one with 4-bit Rice parameters (see Table 23), the first 4 bits of each partition are either a Rice parameter or an escape code. These 4 bits indicate an escape code if they are 0b1111; otherwise, they contain the Rice parameter as an unsigned number. If the coded residual of the current subframe is one with 5-bit Rice parameters, the first 5 bits of each partition indicate an escape code if they are 0b11111; otherwise, they contain the Rice parameter as an unsigned number as well. +

+
+
+

+各パーティションはパラメーターから始まります。サブフレームのコード化された残差が4ビットライスパラメーターを持つものである場合（表23を参照）、各パーティションの最初の4ビットはイネパラメーターまたはエスケープコードのいずれかです。これらの4ビットは、0B1111の場合、エスケープコードを示します。それ以外の場合、それらは署名のない数字としてイネパラメーターを含みます。現在のサブフレームのコード化された残差が5ビットのイネパラメーターを持つものである場合、各パーティションの最初の5ビットは、0B11111の場合、エスケープコードを示します。それ以外の場合は、署名のない数字としてライスパラメーターも含まれています。 +

+
+
+
+
+
+9.2.7.1. Escaped Partition +
+
+
+
+9.2.7.1. 逃げたパーティション +
+
+
+
+
+

+If an escape code was used, the partition does not contain a variable-length Rice-coded residual; rather, it contains a fixed-length unencoded residual. Directly following the escape code are 5 bits containing the number of bits with which each residual sample is stored, as an unsigned number. The residual samples themselves are stored signed two's complement. For example, when a partition is escaped and each residual sample is stored with 3 bits, the number -1 is represented as 0b111. +

+
+
+

+エスケープコードが使用された場合、パーティションには可変長のイネコードされた残差は含まれていません。むしろ、固定された長さの非エンコード残差が含まれています。エスケープコードの直後には、各残差サンプルが保存されているビット数を符号なしの数として含む5ビットがあります。残留サンプル自体には、署名された2つの補数が保存されます。たとえば、パーティションが脱出され、各残差サンプルが3ビットで保存されると、数値-1は0B111として表されます。 +

+
+
+
+
+

+Note that it is possible that the number of bits with which each sample is stored is 0, which means that all residual samples in that partition have a value of 0 and that no bits are used to store the samples. In that case, the partition contains nothing except the escape code and 0b00000. +

+
+
+

+各サンプルが保存されているビット数は0である可能性があることに注意してください。つまり、そのパーティション内のすべての残差サンプルの値は0であり、サンプルの保存にビットが使用されないことを意味します。その場合、パーティションにはエスケープコードと0B00000以外は何も含まれていません。 +

+
+
+
+
+
+9.2.7.2. Rice Code +
+
+
+
+9.2.7.2. 稲法 +
+
+
+
+
+

+If a Rice parameter was provided for a certain partition, that partition contains a Rice-coded residual. The residual samples, which are signed numbers, are represented by unsigned numbers in the Rice code. For positive numbers, the representation is the number doubled. For negative numbers, the representation is the number multiplied by -2 and with 1 subtracted. This representation of signed numbers is also known as zigzag encoding. The zigzag-encoded residual is called the folded residual. +

+
+
+

+特定のパーティションにイネパラメーターが提供された場合、そのパーティションにはイネコードされた残差が含まれています。署名された番号である残留サンプルは、稲法に署名されていない番号で表されます。正の数の場合、表現は数が2倍になります。負の数の場合、表現は数に-2を掛け、1を引いたものです。署名された数字のこの表現は、Zigzagエンコーディングとしても知られています。ジグザグエンコード残差は、折り畳まれた残差と呼ばれます。 +

+
+
+
+
+

+Each folded residual sample is then split into two parts, a most-significant part and a least-significant part. The Rice parameter at the start of each partition determines where that split lies: it is the number of bits in the least-significant part. Each residual sample is then stored by coding the most-significant part as unary, followed by the least-significant part as binary. +

+
+
+

+次に、折り畳まれた各残差サンプルは、最も重要な部分と重要な部分の2つの部分に分割されます。各パーティションの開始時のイネパラメーターは、その分割がどこにあるかを決定します。これは、最も重要でない部分のビット数です。次に、各残差サンプルは、最も重要な部分を単位としてコーディングし、続いてバイナリとして最も重要でない部分をコーディングすることにより保存されます。 +

+
+
+
+
+

+For example, take a partition with Rice parameter 3 containing a folded residual sample with 38 as its value, which is 0b100110 in binary. The most-significant part is 0b100 (4) and is stored in unary form as 0b00001. The least-significant part is 0b110 (6) and is stored as is. The Rice code word is thus 0b00001110. The Rice code words for all residual samples in a partition are stored consecutively. +

+
+
+

+たとえば、バイナリの0B100110である38の折り畳まれた残差サンプルを含むイネパラメーター3のパーティションを取ります。最も重要な部分は0B100（4）であり、0B00001として単位形式で保存されます。最も重要でない部分は0B110（6）であり、そのまま保存されます。したがって、稲法の単語は0b00001110です。パーティション内のすべての残留サンプルの稲法の単語は、連続して保存されます。 +

+
+
+
+
+

+To decode a Rice code word, zero bits must be counted until encountering a one bit, after which a number of bits given by the Rice parameter must be read. The count of zero bits is shifted left by the Rice parameter (i.e., multiplied by 2 raised to the power Rice parameter) and bitwise ORed with (i.e., added to) the read value. This is the folded residual value. An even folded residual value is shifted right 1 bit (i.e., divided by 2) to get the (unfolded) residual value. An odd folded residual value is shifted right 1 bit and then has all bits flipped (1 added to and divided by -2) to get the (unfolded) residual value, subject to negative numbers being signed two's complement on the decoding machine. +

+
+
+

+稲法の単語を解読するには、ゼロビットを1ビットに遭遇するまでカウントする必要があります。その後、米パラメーターで与えられる多数のビットを読み取る必要があります。ゼロビットのカウントは、ライスパラメーター（つまり、パワーライスパラメーターに上げられた2を掛けます）によって残され、読み取り値とビットワイズオレッド（つまり追加）されます。これは折りたたまれた残差値です。均一な折り畳まれた残留値は、（つまり、2で割って）右にシフトされ、（展開された）残差値を取得します。奇妙な折り畳まれた残留値は1ビット正しくシフトされ、すべてのビットが反転し（1に追加され、-2で割られます）、（展開された）残差値を取得します。 +

+
+
+
+
+

+Appendix D shows decoding of a complete coded residual. +

+
+
+

+付録Dは、完全なコード化された残差のデコードを示しています。 +

+
+
+
+
+
+9.2.7.3. Residual Sample Value Limit +
+
+
+
+9.2.7.3. 残留サンプル値制限 +
+
+
+
+
+

+All residual sample values MUST be representable in the range offered by a 32-bit integer, signed one's complement. Equivalently, all residual sample values MUST fall in the range offered by a 32-bit integer signed two's complement, excluding the most negative possible value of that range. This means residual sample values MUST NOT have an absolute value equal to, or larger than, 2 to the power 31. A FLAC encoder MUST make sure of this. If a FLAC encoder is, for a certain subframe, unable to find a suitable predictor for which all residual samples fall within said range, it MUST default to writing a verbatim subframe. Appendix A explains in which circumstances residual samples are already implicitly representable in said range; thus, an additional check is not needed. +

+
+
+

+すべての残差サンプル値は、32ビットの整数によって提供される範囲で表現できるものでなければなりません。同等に、すべての残差サンプル値は、その範囲の最も負の可能な値を除く、32ビットの整数が署名した2つの補数に提供される範囲に収まる必要があります。これは、残留サンプル値が電力31に等しい、または2より大きい絶対値を持たないことを意味します。FLACエンコーダーはこれを確認する必要があります。FLACエンコーダーが、特定のサブフレームについて、すべての残差サンプルが上記の範囲内に該当する適切な予測因子を見つけることができない場合、逐語的なサブフレームを作成する必要があります。付録Aは、どのような状況で、残留サンプルがすでに上記の範囲で暗黙的に表現できるかを説明しています。したがって、追加のチェックは必要ありません。 +

+
+
+
+
+

+The reason for this limit is to ensure that decoders can use 32-bit integers when processing residuals, simplifying decoding. The reason the most negative value of a 32-bit integer signed two's complement is specifically excluded is to prevent decoders from having to implement specific handling of that value, as it cannot be negated within a 32-bit signed integer, and most library routines calculating an absolute value have undefined behavior for processing that value. +

+
+
+

+この制限の理由は、デコーダーが残差を処理するときに32ビット整数を使用してデコードを簡素化できるようにすることです。32ビット整数の2つの補数に署名された32ビット整数の最も負の値が具体的に除外されている理由は、32ビットの署名された整数とほとんどのライブラリルーチン内で否定できないため、デコーダがその値の特定の処理を実装しないようにすることです。絶対値には、その値を処理するための未定義の動作があります。 +

+
+
+
+
+
+9.3. Frame Footer +
+
+
+
+9.3. フレームフッター +
+
+
+
+
+

+Following the last subframe is the frame footer. If the last subframe is not byte aligned (i.e., the number of bits required to store all subframes put together is not divisible by 8), zero bits are added until byte alignment is reached. Following this is a 16-bit CRC, initialized with 0, with the polynomial x^16 + x^15 + x^2 + x^0. This CRC covers the whole frame, excluding the 16-bit CRC but including the sync code. +

+
+
+

+最後のサブフレームに続くのはフレームフッターです。最後のサブフレームがバイトに合わせられていない場合（つまり、すべてのサブフレームをまとめるために必要なビットの数が8で割り切れません）、バイトアライメントに達するまでゼロビットが追加されます。これに続くのは、0で初期化された16ビットCRCで、多項式x^16 + x^15 + x^2 + x^0で初期化されています。このCRCは、16ビットCRCを除くフレーム全体をカバーしますが、同期コードを含みます。 +

+
+
+
+
+
+10. Container Mappings +
+
+
+
+10. コンテナマッピング +
+
+
+
+
+

+The FLAC format can be used without any container, as it already provides for the most basic features normally associated with a container. However, the functionality this basic container provides is rather limited, and for more advanced features (such as combining FLAC audio with video), it needs to be encapsulated by a more capable container. This presents a problem: because of these container features, the FLAC format mixes data that belongs to the encoded data (like block size and sample rate) with data that belongs to the container (like checksum and timecode). The choice was made to encapsulate FLAC frames as they are, which means some data will be duplicated and potentially deviating between the FLAC frames and the encapsulating container. +

+
+
+

+FLAC形式は、コンテナに通常関連付けられている最も基本的な機能を既に提供するため、コンテナなしで使用できます。ただし、この基本的なコンテナが提供する機能はかなり限られており、より高度な機能（FLACオーディオとビデオを組み合わせるなど）の場合、より有能なコンテナによってカプセル化する必要があります。これには問題があります。これらのコンテナ機能のため、FLAC形式は、エンコードされたデータ（ブロックサイズやサンプルレートなど）に属するデータとコンテナ（チェックサムやタイムコードなど）に属するデータを組み合わせます。この選択は、FLACフレームをそのままカプセル化するために行われました。つまり、一部のデータが複製され、FLACフレームとカプセル化コンテナの間で潜在的に逸脱する可能性があります。 +

+
+
+
+
+

+As FLAC frames are completely independent of each other, container format features handling dependencies do not need to be used. For example, all FLAC frames embedded in Matroska are marked as keyframes when they are stored in a SimpleBlock, and tracks in an MP4 file containing only FLAC frames do not need a sync sample box. +

+
+
+

+FLACフレームは互いに完全に独立しているため、コンテナ形式の機能処理依存関係を使用する必要はありません。たとえば、Matroskaに埋め込まれたすべてのFLACフレームは、SimpleBlockに保存されているときにキーフレームとしてマークされ、FLACフレームのみを含むMP4ファイルのトラックには同期サンプルボックスが必要ありません。 +

+
+
+
+
+
+10.1. Ogg Mapping +
+
+
+
+10.1. OGGマッピング +
+
+
+
+
+

+The Ogg container format is defined in [RFC3533]. The first packet of a logical bitstream carrying FLAC data is structured according to the following table. +

+
+
+

+OGGコンテナ形式は[RFC3533]で定義されています。FLACデータを運ぶ論理的なビットストリームの最初のパケットは、次の表に従って構成されています。 +

+
+
+
+
+ 
++=========+=========================================================+
+| Data    | Description                                             |
++=========+=========================================================+
+| 5       | Bytes 0x7F 0x46 0x4C 0x41 0x43 (as also defined by      |
+| bytes   | [RFC5334]).                                             |
++---------+---------------------------------------------------------+
+| 2       | Version number of the FLAC-in-Ogg mapping.  These bytes |
+| bytes   | are 0x01 0x00, meaning version 1.0 of the mapping.      |
++---------+---------------------------------------------------------+
+| 2       | Number of header packets (excluding the first header    |
+| bytes   | packet) as an unsigned number coded big-endian.         |
++---------+---------------------------------------------------------+
+| 4       | The fLaC signature.                                     |
+| bytes   |                                                         |
++---------+---------------------------------------------------------+
+| 4       | A metadata block header for the streaminfo metadata     |
+| bytes   | block.                                                  |
++---------+---------------------------------------------------------+
+| 34      | A streaminfo metadata block.                            |
+| bytes   |                                                         |
++---------+---------------------------------------------------------+
+
+                               Table 24
+
+
+
+
+
+

+The number of header packets MAY be 0, which means the number of packets that follow is unknown. This first packet MUST NOT share a Ogg page with any other packets. This means the first page of a logical stream of FLAC-in-Ogg is always 79 bytes. +

+
+
+

+ヘッダーパケットの数は0である可能性があります。つまり、続くパケットの数は不明です。この最初のパケットは、OGGページを他のパケットと共有してはなりません。これは、FLAC-IN-GGの論理ストリームの最初のページが常に79バイトであることを意味します。 +

+
+
+
+
+

+Following the first packet are one or more header packets, each of which contains a single metadata block. The first of these packets SHOULD be a Vorbis comment metadata block for historic reasons. This is contrary to unencapsulated FLAC streams, where the order of metadata blocks is not important except for the streaminfo metadata block and where a Vorbis comment metadata block is optional. +

+
+
+

+最初のパケットに続くのは、1つ以上のヘッダーパケットがあり、それぞれには単一のメタデータブロックが含まれています。これらのパケットの最初は、歴史的な理由でVorbisコメントメタデータブロックである必要があります。これは、カプセル化されていないFLACストリームに反します。メタデータブロックの順序は、Streaminfoメタデータブロックを除き、Vorbisコメントメタデータブロックがオプションである場合を除きます。 +

+
+
+
+
+

+Following the header packets are audio packets. Each audio packet contains a single FLAC frame. The first audio packet MUST start on a new Ogg page, i.e., the last metadata block MUST finish its page before any audio packets are encapsulated. +

+
+
+

+ヘッダーパケットに続くのはオーディオパケットです。各オーディオパケットには、単一のFLACフレームが含まれています。最初のオーディオパケットは、新しいOGGページで開始する必要があります。つまり、オーディオパケットがカプセル化される前に、最後のメタデータブロックがページを終了する必要があります。 +

+
+
+
+
+

+The granule position of all pages containing header packets MUST be 0. For pages containing audio packets, the granule position is the number of the last sample contained in the last completed packet in the frame. The sample numbering considers interchannel samples. If a page contains no packet end (e.g., when it only contains the start of a large packet that continues on the next page), then the granule position is set to the maximum value possible, i.e., 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF. +

+
+
+

+ヘッダーパケットを含むすべてのページの顆粒位置は0でなければなりません。オーディオパケットを含むページの場合、顆粒位置は、フレームの最後の完成したパケットに含まれる最後のサンプルの数です。サンプル番号は、チャネルインターチャネルサンプルを考慮します。ページにパケットエンドが含まれていない場合（たとえば、次のページで継続する大きなパケットの開始のみを含む場合）、顆粒位置は可能な最大値に設定されます。つまり、0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff。 +

+
+
+
+
+

+The granule position of the first audio data page with a completed packet MAY be larger than the number of samples contained in packets that complete on that page. In other words, the apparent sample number of the first sample in the stream following from the granule position and the audio data MAY be larger than 0. This allows, for example, a server to cast a live stream to several clients that joined at different moments without rewriting the granule position for each client. +

+
+
+

+完成したパケットを使用した最初のオーディオデータページの顆粒位置は、そのページに完成するパケットに含まれるサンプルの数よりも大きい場合があります。言い換えれば、顆粒位置から続くストリームの最初のサンプルの見かけのサンプル番号とオーディオデータは0より大きくなる可能性があります。これにより、たとえば、異なるものに結合した複数のクライアントにライブストリームをキャストすることができます。各クライアントの顆粒位置を書き換えない瞬間。 +

+
+
+
+
+

+If an audio stream is encoded where audio properties (sample rate, number of channels, or bit depth) change at some point in the stream, this should be dealt with by finishing encoding of the current Ogg stream and starting a new Ogg stream, concatenated to the previous one. This is called chaining in Ogg. See the Ogg specification [RFC3533] for details. +

+
+
+

+ストリームのある時点でオーディオプロパティ（サンプルレート、チャネル数、またはビット深度）が変更される場合にオーディオストリームがエンコードされている場合、これは現在のOGGストリームのエンコードを完了し、新しいOGGストリームを開始することで対処する必要があります。前のものに。これはOGGでチェーンと呼ばれます。詳細については、OGG仕様[RFC3533]を参照してください。 +

+
+
+
+
+
+10.2. Matroska Mapping +
+
+
+
+10.2. マトロスカマッピング +
+
+
+
+
+

+The Matroska container format is defined in [RFC9559]. The codec ID (EBML path \Segment\Tracks\TrackEntry\CodecID) assigned to signal tracks carrying FLAC data is A_FLAC in ASCII. All FLAC data before the first audio frame (i.e., the fLaC ASCII signature and all metadata blocks) is stored as CodecPrivate data (EBML path \Segment\Tracks\TrackEntry\CodecPrivate). +

+
+
+

+マトロスカコンテナ形式は[RFC9559]で定義されています。FLACデータを運ぶ信号トラックに割り当てられたCodec ID（EBML PATH \ Segment \ Tracks \ TrackEntry \ CodeCID）は、ASCIIのA_FLACです。最初のオーディオフレームの前のすべてのFLACデータ（つまり、FLAC ASCII署名およびすべてのメタデータブロック）は、CodecPrivateデータ（EBML Path \ segment \ tracks \ trackentry \ codecprivate）として保存されます。 +

+
+
+
+
+

+Each FLAC frame (including all of its subframes) is treated as a single frame in the context of Matroska. +

+
+
+

+各FLACフレーム（すべてのサブフレームを含む）は、マトロスカのコンテキストで単一のフレームとして扱われます。 +

+
+
+
+
+

+If an audio stream is encoded where audio properties (sample rate, number of channels, or bit depth) change at some point in the stream, this should be dealt with by finishing the current Matroska segment and starting a new one with the new properties. +

+
+
+

+ストリームのある時点でオーディオプロパティ（サンプルレート、チャネル数、またはビット深度）が変更される場合にオーディオストリームがエンコードされている場合、これは現在のMatroskaセグメントを完了し、新しいプロパティで新しいものを開始することで対処する必要があります。 +

+
+
+
+
+
+10.3. ISO Base Media File Format (MP4) Mapping +
+
+
+
+10.3. ISOベースメディアファイル形式（MP4）マッピング +
+
+
+
+
+

+The full encapsulation definition of FLAC audio in MP4 files was deemed too extensive to include in this document. A definition document can be found at [FLAC-in-MP4-specification]. +

+
+
+

+MP4ファイルのFLACオーディオの完全なカプセル化定義は、このドキュメントに含めるには広すぎると見なされました。[FLAC-IN-MP4仕様]に定義ドキュメントがあります。 +

+
+
+
+
+
+11. Security Considerations +
+
+
+
+11. セキュリティに関する考慮事項 +
+
+
+
+
+

+Like any other codec (such as [RFC6716]), FLAC should not be used with insecure ciphers or cipher modes that are vulnerable to known plaintext attacks. Some of the header bits, as well as the padding, are easily predictable. +

+
+
+

+他のコーデック（[RFC6716]など）と同様に、FLACは、既知のプレーンテキスト攻撃に対して脆弱な不安定な暗号や暗号モードで使用しないでください。ヘッダービットの一部とパディングは、簡単に予測できます。 +

+
+
+
+
+

+Implementations of the FLAC codec need to take appropriate security considerations into account. Section 2.1 of [RFC4732] provides general information on DoS attacks on end systems and describes some mitigation strategies. Areas of concern specific to FLAC follow. +

+
+
+

+FLACコーデックの実装は、適切なセキュリティ上の考慮事項を考慮する必要があります。[RFC4732]のセクション2.1は、ENDシステムに対するDOS攻撃に関する一般的な情報を提供し、いくつかの緩和戦略について説明します。FLACに固有の懸念領域が続きます。 +

+
+
+
+
+

+It is extremely important for the decoder to be robust against malformed payloads. Payloads that do not conform to this specification MUST NOT cause the decoder to overrun its allocated memory or take an excessive amount of resources to decode. An overrun in allocated memory could lead to arbitrary code execution by an attacker. The same applies to the encoder, even though problems with encoders are typically rarer. Malformed audio streams MUST NOT cause the encoder to misbehave because this would allow an attacker to attack transcoding gateways. +

+
+
+

+デコーダーが奇形のペイロードに対して堅牢であることが非常に重要です。この仕様に準拠していないペイロードは、デコーダーが割り当てられたメモリをオーバーランさせたり、過度の量のリソースを取得してデコードしてはなりません。割り当てられたメモリのオーバーランは、攻撃者による任意のコード実行につながる可能性があります。エンコーダーの問題は通常よりまれですが、エンコーダーにも同じことが当てはまります。奇形のオーディオストリームは、攻撃者がトランスコーディングゲートウェイを攻撃できるため、エンコーダーを不正にしてはなりません。 +

+
+
+
+
+

+As with all compression algorithms, both encoding and decoding can produce an output much larger than the input. For decoding, the most extreme possible case of this is a frame with eight constant subframes of block size 65535 and coding for 32-bit PCM. This frame is only 49 bytes in size but codes for more than 2 megabytes of uncompressed PCM data. For encoding, it is possible to have an even larger size increase, although such behavior is generally considered faulty. This happens if the encoder chooses a Rice parameter that does not fit with the residual that has to be encoded. In such a case, very long unary-coded symbols can appear (in the most extreme case, more than 4 gigabytes per sample). Decoder and encoder implementors are advised to take precautions to prevent excessive resource utilization in such cases. +

+
+
+

+すべての圧縮アルゴリズムと同様に、エンコードとデコードの両方が入力よりもはるかに大きい出力を生成する可能性があります。デコードの場合、これの最も極端なケースは、ブロックサイズ65535の8つの一定のサブフレームと32ビットPCMのコーディングを備えたフレームです。このフレームのサイズはわずか49バイトですが、2メガバイト以上の非圧縮PCMデータをコードします。エンコーディングの場合、そのような動作は一般に故障していると考えられていますが、さらに大きくサイズが増加する可能性があります。これは、エンコーダーがエンコードする必要がある残差に適合しないイネパラメーターを選択した場合に発生します。そのような場合、非常に長い単一コードされた記号が表示されます（最も極端な場合、サンプルごとに4ギガバイト以上）。デコーダーとエンコーダーの実装者は、そのような場合に過度のリソースの利用を防ぐために予防策を講じることをお勧めします。 +

+
+
+
+
+

+Where metadata is handled, implementors are advised to either thoroughly test the handling of extreme cases or impose reasonable limits beyond the limits of this specification. For example, a single Vorbis comment metadata block can contain millions of valid fields. It is unlikely such a limit is ever reached except in a potentially malicious file. Likewise, the media type and description of a picture metadata block can be millions of characters long, despite there being no reasonable use of such contents. One possible use case for very long character strings is in lyrics, which can be stored in Vorbis comment metadata block fields. +

+
+
+

+メタデータが処理される場合、実装者は、極端なケースの取り扱いを徹底的にテストするか、この仕様の制限を超えて合理的な制限を課すことをお勧めします。たとえば、単一のVorbisコメントメタデータブロックには、何百万もの有効なフィールドを含めることができます。潜在的に悪意のあるファイルを除いて、このような制限に達する可能性は低いです。同様に、そのようなコンテンツの合理的な使用がないにもかかわらず、画像メタデータブロックのメディアタイプと説明は何百万人もの文字になります。非常に長いキャラクター文字列の可能なユースケースの1つは歌詞で、Vorbisコメントメタデータブロックフィールドに保存できます。 +

+
+
+
+
+

+Various kinds of metadata blocks contain length fields or field counts. While reading a block following these lengths or counts, a decoder MUST make sure higher-level lengths or counts (most importantly, the length field of the metadata block itself) are not exceeded. As some of these length fields code string lengths and memory must be allocated for that, parsers MUST first verify that a block is valid before allocating memory based on its contents, except when explicitly instructed to salvage data from a malformed file. +

+
+
+

+さまざまな種類のメタデータブロックには、長さのフィールドまたはフィールド数が含まれています。これらの長さまたはカウントに続いてブロックを読み取っている間、デコーダーは、より高いレベルの長さまたはカウント（最も重要なことに、メタデータブロック自体の長さフィールド）を超えないことを確認する必要があります。これらの長さのフィールドの一部は、文字列の長さとメモリを割り当てる必要があるため、パーサーはまず、不正なファイルからデータをサルベージするように明示的に指示された場合を除き、その内容に基づいてメモリを割り当てる前にブロックが有効であることを確認する必要があります。 +

+
+
+
+
+

+Metadata blocks can also contain references, e.g., the picture metadata block can contain a URI. When following a URI, the security considerations of [RFC3986] apply. Applications MUST obtain explicit user approval to retrieve resources via remote protocols. Following external URIs introduces a tracking risk from on-path observers and the operator of the service hosting the URI. Likewise, the choice of scheme, if it isn't protected like https, could also introduce integrity attacks by an on-path observer. A malicious operator of the service hosting the URI can return arbitrary content that the parser will read. Also, such retrievals can be used in a DDoS attack when the URI points to a potential victim. Therefore, applications need to ask user approval for each retrieval individually, take extra precautions when parsing retrieved data, and cache retrieved resources. Applications MUST obtain explicit user approval to retrieve local resources not located in the same directory as the FLAC file being processed. Since relative URIs are permitted, applications MUST guard against directory traversal attacks and guard against a violation of a same-origin policy if such a policy is being enforced. +

+
+
+

+メタデータブロックには参照を含めることもできます。たとえば、画像メタデータブロックにはURIを含めることができます。URIに従うと、[RFC3986]のセキュリティ上の考慮事項が適用されます。アプリケーションは、リモートプロトコルを介してリソースを取得するための明示的なユーザー承認を取得する必要があります。外部のURIに続いて、Path ObserversとURIをホストするサービスのオペレーターから追跡リスクを導入します。同様に、スキームの選択は、HTTPSのように保護されていない場合、パスでのオブザーバーによる整合性攻撃を導入することもできます。URIをホストするサービスの悪意のあるオペレーターは、パーサーが読む任意のコンテンツを返すことができます。また、URIが潜在的な犠牲者を指している場合、このような検索はDDOS攻撃で使用できます。したがって、アプリケーションは、各検索のユーザーの承認を個別に承認し、取得したデータを解析するときに追加の予防策を講じ、取得したリソースをキャッシュする必要があります。アプリケーションは、処理されているFLACファイルと同じディレクトリにないローカルリソースを取得するために、明示的なユーザー承認を取得する必要があります。相対的なURIは許可されているため、申請書はディレクトリのトラバーサル攻撃を防ぎ、そのようなポリシーが施行されている場合、同性ポリシーの違反を防ぐ必要があります。 +

+
+
+
+
+

+Seeking in a FLAC stream that is not in a container relies on the coded number in frame headers and optionally a seek table metadata block. Parsers MUST employ thorough checks on whether a found coded number or seek point is at all possible, e.g., whether it is within bounds and not directly contradicting any other coded number or seek point that the seeking process relies on. Without these checks, seeking might get stuck in an infinite loop when numbers in frames are non-consecutive or otherwise not valid, which could be used in DoS attacks. +

+
+
+

+コンテナ内にないFLACストリームでの探索は、フレームヘッダーのコード化された数値に依存しており、オプションではシークテーブルメタデータブロックに依存しています。パーサーは、見つかったコード化された数字またはシークポイントが可能であるかどうかを徹底的なチェックを使用する必要があります。たとえば、それが範囲内であり、他のコード化された数値と直接矛盾しないか、シークプロセスが依存しているポイントを求めています。これらのチェックがなければ、Framesの数値が非継続的または無効である場合、DOS攻撃で使用できる場合、探すことは無限のループで立ち往生する可能性があります。 +

+
+
+
+
+

+Implementors are advised to employ fuzz testing combined with different sanitizers on FLAC decoders to find security problems. Ignoring the results of CRC checks improves the efficiency of decoder fuzz testing. +

+
+
+

+実装者は、セキュリティの問題を見つけるために、FLACデコーダー上のさまざまな消毒剤と組み合わせたファズテストを採用することをお勧めします。CRCチェックの結果を無視すると、デコーダーファズテストの効率が向上します。 +

+
+
+
+
+

+See [FLAC-decoder-testbench] for a non-exhaustive list of FLAC files with extreme configurations that lead to crashes or reboots on some known implementations. Besides providing a starting point for security testing, this set of files can also be used to test conformance with this specification. +

+
+
+

+[FLAC-Decoder-Testbench]を参照して、既知の実装でクラッシュまたは再起動につながる極端な構成を備えたFLACファイルの網羅的ではないリストを参照してください。セキュリティテストの出発点を提供することに加えて、この一連のファイルを使用して、この仕様との適合性をテストすることもできます。 +

+
+
+
+
+

+FLAC files may contain executable code, although the FLAC format is not designed for it and it is uncommon. One use case where FLAC is occasionally used to store executable code is when compressing images of mixed-mode CDs, which contain both audio and non-audio data, the non-audio portion of which can contain executable code. In that case, the executable code is stored as if it were audio and is potentially obscured. Of course, it is also possible to store executable code as metadata, for example, as a Vorbis comment with help of a binary-to-text encoding or directly in an application metadata block. Applications MUST NOT execute code contained in FLAC files or present parts of FLAC files as executable code to the user, except when an application has that explicit purpose, e.g., applications reading FLAC files as disc images and presenting it as a virtual disc drive. +

+
+
+

+FLACファイルには実行可能なコードが含まれている場合がありますが、FLAC形式は設計されておらず、まれです。実行可能性コードの保存にFLACが時々使用される場合の1つのユースケースは、オーディオデータと非オーディオデータの両方を含む混合モードCDの画像を圧縮するときに、実行可能なコードを含むことができます。その場合、実行可能コードはオーディオであるかのように保存され、潜在的に不明瞭になります。もちろん、たとえば、実行可能性コードをメタデータとして保存することもできます。たとえば、バイナリからテキストのエンコードの助けを借りて、またはアプリケーションメタデータブロックに直接vorbisコメントとして保存することもできます。アプリケーションは、FLACファイルに含まれるコードを実行したり、FLACファイルの部分をユーザーに実行可能なコードとして提示したりしてはなりません。たとえば、アプリケーションにFLACファイルをDISC画像として読み取り、仮想ディスクドライブとして提示するアプリケーションがある場合を除きます。 +

+
+
+
+
+
+12. IANA Considerations +
+
+
+
+12. IANAの考慮事項 +
+
+
+
+
+

+Per this document, IANA has registered one new media type ("audio/ flac") and created a new IANA registry, as described in the subsections below. +

+
+
+

+このドキュメントに従って、IANAは1つの新しいメディアタイプ（「Audio/ FLAC」）を登録し、以下のサブセクションで説明するように、新しいIANAレジストリを作成しました。 +

+
+
+
+
+
+12.1. Media Type Registration +
+
+
+
+12.1. メディアタイプの登録 +
+
+
+
+
+

+IANA has registered the "audio/flac" media type as follows. This media type is applicable for FLAC audio that is not packaged in a container as described in Section 10. FLAC audio packaged in such a container will take on the media type of that container, for example, "audio/ogg" when packaged in an Ogg container or "video/mp4" when packaged in an MP4 container alongside a video track. +

+
+
+

+IANAは、次のように「オーディオ/FLAC」メディアタイプを登録しています。このメディアタイプは、セクション10で説明されているようにコンテナにパッケージ化されていないFLACオーディオに適用されます。そのようなコンテナにパッケージ化されたFLACオーディオは、そのコンテナのメディアタイプ、たとえば、「オーディオ/OGG」を使用します。MP4コンテナにビデオトラックと一緒にパッケージ化された場合、OGGコンテナまたは「ビデオ/MP4」。 +

+
+
+
+
+

+Type name: +

+
+
+

+タイプ名： +

+
+
+
+
+

+audio +

+
+
+

+オーディオ +

+
+
+
+
+

+Subtype name: +

+
+
+

+サブタイプ名： +

+
+
+
+
+

+flac +

+
+
+

+FLAC +

+
+
+
+
+

+Required parameters: +

+
+
+

+必要なパラメーター： +

+
+
+
+
+

+N/A +

+
+
+

+n/a +

+
+
+
+
+

+Optional parameters: +

+
+
+

+オプションのパラメーター： +

+
+
+
+
+

+N/A +

+
+
+

+n/a +

+
+
+
+
+

+Encoding considerations: +

+
+
+

+考慮事項のエンコード： +

+
+
+
+
+

+as per RFC 9639 +

+
+
+

+RFC 9639に従って +

+
+
+
+
+

+Security considerations: +

+
+
+

+セキュリティ上の考慮事項： +

+
+
+
+
+

+See the security considerations in Section 11 of RFC 9639. +

+
+
+

+RFC 9639のセクション11のセキュリティ上の考慮事項を参照してください。 +

+
+
+
+
+

+Interoperability considerations: +

+
+
+

+相互運用性の考慮事項： +

+
+
+
+
+

+See the descriptions of past format changes in Appendix B of RFC 9639. +

+
+
+

+RFC 9639の付録Bの過去の形式の変更の説明を参照してください。 +

+
+
+
+
+

+Published specification: +

+
+
+

+公開された仕様： +

+
+
+
+
+

+RFC 9639 +

+
+
+

+RFC 9639 +

+
+
+
+
+

+Applications that use this media type: +

+
+
+

+このメディアタイプを使用するアプリケーション： +

+
+
+
+
+

+FFmpeg, Apache, Firefox +

+
+
+

+ffmpeg、Apache、Firefox +

+
+
+
+
+

+Fragment identifier considerations: +

+
+
+

+フラグメント識別子の考慮事項： +

+
+
+
+
+

+N/A +

+
+
+

+n/a +

+
+
+
+
+

+Additional information: +

+
+
+

+追加情報： +

+
+
+
+
+

+Deprecated alias names for this type: +

+
+
+

+このタイプの非推奨エイリアス名： +

+
+
+
+
+

+audio/x-flac +

+
+
+

+オーディオ/X-FLAC +

+
+
+
+
+

+Magic number(s): +

+
+
+

+マジックナンバー： +

+
+
+
+
+

+fLaC +

+
+
+

+FLAC +

+
+
+
+
+

+File extension(s): +

+
+
+

+ファイル拡張子： +

+
+
+
+
+

+flac +

+
+
+

+FLAC +

+
+
+
+
+

+Macintosh file type code(s): +

+
+
+

+Macintoshファイルタイプコード： +

+
+
+
+
+

+N/A +

+
+
+

+n/a +

+
+
+
+
+

+Uniform Type Identifier: +

+
+
+

+均一型識別子： +

+
+
+
+
+

+org.xiph.flac conforms to public.audio +

+
+
+

+org.xiph.flacはpublic.audioに準拠しています +

+
+
+
+
+

+Windows Clipboard Format Name: +

+
+
+

+Windows Clipboardフォーマット名： +

+
+
+
+
+

+audio/flac +

+
+
+

+オーディオ/FLAC +

+
+
+
+
+

+Person & email address to contact for further information: +

+
+
+

+詳細については、連絡先への個人およびメールアドレス： +

+
+
+
+
+

+IETF CELLAR Working Group (cellar@ietf.org) +

+
+
+

+IETFセラーワーキンググループ（cellar@ietf.org） +

+
+
+
+
+

+Intended usage: +

+
+
+

+意図された使用法： +

+
+
+
+
+

+COMMON +

+
+
+

+一般 +

+
+
+
+
+

+Restrictions on usage: +

+
+
+

+使用に関する制限： +

+
+
+
+
+

+N/A +

+
+
+

+n/a +

+
+
+
+
+

+Author: +

+
+
+

+著者： +

+
+
+
+
+

+IETF CELLAR Working Group +

+
+
+

+IETFセラーワーキンググループ +

+
+
+
+
+

+Change controller: +

+
+
+

+Change Controller： +

+
+
+
+
+

+Internet Engineering Task Force (iesg@ietf.org) +

+
+
+

+インターネットエンジニアリングタスクフォース（iesg@ietf.org） +

+
+
+
+
+
+12.2. FLAC Application Metadata Block IDs Registry +
+
+
+
+12.2. FLACアプリケーションメタデータブロックIDレジストリ +
+
+
+
+
+

+IANA has created a new registry called the "FLAC Application Metadata Block IDs" registry. The values correspond to the 32-bit identifier described in Section 8.4. +

+
+
+

+IANAは、「FLACアプリケーションメタデータブロックID」レジストリと呼ばれる新しいレジストリを作成しました。値は、セクション8.4で説明されている32ビット識別子に対応しています。 +

+
+
+
+
+

+To register a new application ID in this registry, one needs an application ID, a description, an optional reference to a document describing the application ID, and a Change Controller (IETF or email of registrant). The application IDs are allocated according to the "First Come First Served" policy [RFC8126] so that there is no impediment to registering any application IDs the FLAC community encounters, especially if they were used in audio files but were not registered when the audio files were encoded. An application ID can be any 32-bit value but is often composed of 4 ASCII characters that are human-readable. +

+
+
+

+このレジストリに新しいアプリケーションIDを登録するには、アプリケーションID、説明、アプリケーションIDを説明するドキュメントへのオプションの参照、およびChange Controller（IETFまたは登録者の電子メール）が必要です。アプリケーションIDは、「First Come First」ポリシー[RFC8126]に従って割り当てられます。そのため、特にオーディオファイルで使用されているがオーディオファイルが登録されていない場合、FLACコミュニティの遭遇を登録することに障害がありません。エンコードされました。アプリケーションIDは任意の32ビット値にすることができますが、多くの場合、人間が読み取る可能性のある4つのASCII文字で構成されています。 +

+
+
+
+
+

+The initial contents of "FLAC Application Metadata Block IDs" registry are shown in the table below. These initial values were taken from the registration page at xiph.org (see [ID-registration-page]), which is no longer being maintained as it has been replaced by this registry. +

+
+
+

+「FLACアプリケーションメタデータブロックID」レジストリの初期内容を以下の表に示します。これらの初期値は、xiph.orgの登録ページ（[id-registration-page]を参照）から取得されましたが、このレジストリに置き換えられたため、維持されなくなりました。 +

+
+
+
+
+ 
+  +===========+==========+===========+===================+==========+
+  |Application|ASCII     |Description|Reference          |Change    |
+  |ID         |Rendition |           |                   |Controller|
+  |           |(If       |           |                   |          |
+  |           |Available)|           |                   |          |
+  +===========+==========+===========+===================+==========+
+  |0x41544348 |ATCH      |FlacFile   |[FlacFile], RFC    |IETF      |
+  |           |          |           |9639               |          |
+  +-----------+----------+-----------+-------------------+----------+
+  |0x42534F4C |BSOL      |beSolo     |RFC 9639           |IETF      |
+  +-----------+----------+-----------+-------------------+----------+
+  |0x42554753 |BUGS      |Bugs Player|RFC 9639           |IETF      |
+  +-----------+----------+-----------+-------------------+----------+
+  |0x43756573 |Cues      |GoldWave   |RFC 9639           |IETF      |
+  |           |          |cue points |                   |          |
+  +-----------+----------+-----------+-------------------+----------+
+  |0x46696361 |Fica      |CUE        |RFC 9639           |IETF      |
+  |           |          |Splitter   |                   |          |
+  +-----------+----------+-----------+-------------------+----------+
+  |0x46746F6C |Ftol      |flac-tools |RFC 9639           |IETF      |
+  +-----------+----------+-----------+-------------------+----------+
+  |0x4D4F5442 |MOTB      |MOTB       |RFC 9639           |IETF      |
+  |           |          |MetaCzar   |                   |          |
+  +-----------+----------+-----------+-------------------+----------+
+  |0x4D505345 |MPSE      |MP3 Stream |RFC 9639           |IETF      |
+  |           |          |Editor     |                   |          |
+  +-----------+----------+-----------+-------------------+----------+
+  |0x4D754D4C |MuML      |MusicML:   |RFC 9639           |IETF      |
+  |           |          |Music      |                   |          |
+  |           |          |Metadata   |                   |          |
+  |           |          |Language   |                   |          |
+  +-----------+----------+-----------+-------------------+----------+
+  |0x52494646 |RIFF      |Sound      |RFC 9639           |IETF      |
+  |           |          |Devices    |                   |          |
+  |           |          |RIFF chunk |                   |          |
+  |           |          |storage    |                   |          |
+  +-----------+----------+-----------+-------------------+----------+
+  |0x5346464C |SFFL      |Sound Font |RFC 9639           |IETF      |
+  |           |          |FLAC       |                   |          |
+  +-----------+----------+-----------+-------------------+----------+
+  |0x534F4E59 |SONY      |Sony       |RFC 9639           |IETF      |
+  |           |          |Creative   |                   |          |
+  |           |          |Software   |                   |          |
+  +-----------+----------+-----------+-------------------+----------+
+  |0x5351455A |SQEZ      |flacsqueeze|RFC 9639           |IETF      |
+  +-----------+----------+-----------+-------------------+----------+
+  |0x54745776 |TtWv      |TwistedWave|RFC 9639           |IETF      |
+  +-----------+----------+-----------+-------------------+----------+
+  |0x55495453 |UITS      |UITS       |RFC 9639           |IETF      |
+  |           |          |Embedding  |                   |          |
+  |           |          |tools      |                   |          |
+  +-----------+----------+-----------+-------------------+----------+
+  |0x61696666 |aiff      |FLAC AIFF  |[Foreign-metadata],|IETF      |
+  |           |          |chunk      |RFC 9639           |          |
+  |           |          |storage    |                   |          |
+  +-----------+----------+-----------+-------------------+----------+
+  |0x696D6167 |imag      |flac-image |RFC 9639           |IETF      |
+  +-----------+----------+-----------+-------------------+----------+
+  |0x7065656D |peem      |Parseable  |RFC 9639           |IETF      |
+  |           |          |Embedded   |                   |          |
+  |           |          |Extensible |                   |          |
+  |           |          |Metadata   |                   |          |
+  +-----------+----------+-----------+-------------------+----------+
+  |0x71667374 |qfst      |QFLAC      |RFC 9639           |IETF      |
+  |           |          |Studio     |                   |          |
+  +-----------+----------+-----------+-------------------+----------+
+  |0x72696666 |riff      |FLAC RIFF  |[Foreign-metadata],|IETF      |
+  |           |          |chunk      |RFC 9639           |          |
+  |           |          |storage    |                   |          |
+  +-----------+----------+-----------+-------------------+----------+
+  |0x74756E65 |tune      |TagTuner   |RFC 9639           |IETF      |
+  +-----------+----------+-----------+-------------------+----------+
+  |0x77363420 |w64       |FLAC Wave64|[Foreign-metadata],|IETF      |
+  |           |          |chunk      |RFC 9639           |          |
+  |           |          |storage    |                   |          |
+  +-----------+----------+-----------+-------------------+----------+
+  |0x78626174 |xbat      |XBAT       |RFC 9639           |IETF      |
+  +-----------+----------+-----------+-------------------+----------+
+  |0x786D6364 |xmcd      |xmcd       |RFC 9639           |IETF      |
+  +-----------+----------+-----------+-------------------+----------+
+
+                                Table 25
+
+
+
+
+
+
+13. References +
+
+
+
+13. 参考文献 +
+
+
+
+
+
+13.1. Normative References +
+
+
+
+13.1. 引用文献 +
+
+
+
+
+ 
+   [ISRC-handbook]
+              International ISRC Registration Authority, "International
+              Standard Recording Code (ISRC) Handbook", 4th edition,
+              2021, <https://www.ifpi.org/isrc_handbook/>.
+
+
+
+
+
+ 
+   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
+              DOI 10.17487/RFC1321, April 1992,
+              <https://www.rfc-editor.org/info/rfc1321>.
+
+
+
+
+
+ 
+   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+              Extensions (MIME) Part Two: Media Types", RFC 2046,
+              DOI 10.17487/RFC2046, November 1996,
+              <https://www.rfc-editor.org/info/rfc2046>.
+
+
+
+
+
+ 
+   [RFC2083]  Boutell, T., "PNG (Portable Network Graphics)
+              Specification Version 1.0", RFC 2083,
+              DOI 10.17487/RFC2083, March 1997,
+              <https://www.rfc-editor.org/info/rfc2083>.
+
+
+
+
+
+ 
+   [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>.
+
+
+
+
+
+ 
+   [RFC3533]  Pfeiffer, S., "The Ogg Encapsulation Format Version 0",
+              RFC 3533, DOI 10.17487/RFC3533, May 2003,
+              <https://www.rfc-editor.org/info/rfc3533>.
+
+
+
+
+
+ 
+   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
+              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
+              2003, <https://www.rfc-editor.org/info/rfc3629>.
+
+
+
+
+
+ 
+   [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>.
+
+
+
+
+
+ 
+   [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>.
+
+
+
+
+
+ 
+   [RFC9559]  Lhomme, S., Bunkus, M., and D. Rice, "Matroska Media
+              Container Format Specification", RFC 9559,
+              DOI 10.17487/RFC9559, October 2024,
+              <https://www.rfc-editor.org/info/rfc9559>.
+
+
+
+
+
+
+13.2. Informative References +
+
+
+
+13.2. 参考引用 +
+
+
+
+
+ 
+   [Durbin]   Durbin, J., "The Fitting of Time-Series Models", Revue de
+              l'Institut International de Statistique / Review of the
+              International Statistical Institute, vol. 28, no. 3, pp.
+              233-44, DOI 10.2307/1401322, 1960,
+              <https://www.jstor.org/stable/1401322>.
+
+
+
+
+
+ 
+   [FIR]      Wikipedia, "Finite impulse response", August 2024,
+              <https://en.wikipedia.org/w/
+              index.php?title=Finite_impulse_response&oldid=1240945295>.
+
+
+
+
+
+ 
+   [FLAC-decoder-testbench]
+              "The Free Lossless Audio Codec (FLAC) test files", commit
+              aa7b0c6, August 2023,
+              <https://github.com/ietf-wg-cellar/flac-test-files>.
+
+
+
+
+
+ 
+   [FLAC-implementation]
+              "FLAC", <https://xiph.org/flac/>.
+
+
+
+
+
+ 
+   [FLAC-in-MP4-specification]
+              "Encapsulation of FLAC in ISO Base Media File Format",
+              commit 78d85dd, July 2022,
+              <https://github.com/xiph/flac/blob/master/doc/
+              isoflac.txt>.
+
+
+
+
+
+ 
+   [FLAC-specification-github]
+              "The Free Lossless Audio Codec (FLAC) Specification",
+              <https://github.com/ietf-wg-cellar/flac-specification>.
+
+
+
+
+
+ 
+   [FLAC-wiki-interoperability]
+              "Interoperability considerations", commit 58a06d6,
+              <https://github.com/ietf-wg-cellar/flac-
+              specification/wiki/Interoperability-considerations>.
+
+
+
+
+
+ 
+   [FlacFile] "FlacFile", Wayback Machine archive, October 2007,
+              <https://web.archive.org/web/20071023070305/
+              http://firestuff.org:80/flacfile/>.
+
+
+
+
+
+ 
+   [Foreign-metadata]
+              "Specification of foreign metadata storage in FLAC",
+              commit 72787c3, November 2023,
+              <https://github.com/xiph/flac/blob/master/doc/
+              foreign_metadata_storage.md>.
+
+
+
+
+
+ 
+   [ID-registration-page]
+              Xiph.Org, "ID registry", <https://xiph.org/flac/id.html>.
+
+
+
+
+
+ 
+   [ID3v2]    Nilsson, M., "ID3 tag version 2.4.0 - Native Frames",
+              Wayback Machine archive, November 2000,
+              <https://web.archive.org/web/20220903174949/
+              https://id3.org/id3v2.4.0-frames>.
+
+
+
+
+
+ 
+   [IEC.60908.1999]
+              International Electrotechnical Commission, "Audio
+              recording - Compact disc digital audio system",
+              IEC 60908:1999-02, 1999,
+              <https://webstore.iec.ch/publication/3885>.
+
+
+
+
+
+ 
+   [LinearPrediction]
+              Wikipedia, "Linear prediction", August 2023,
+              <https://en.wikipedia.org/w/
+              index.php?title=Linear_prediction&oldid=1169015573>.
+
+
+
+
+
+ 
+   [Lossless-Compression]
+              Hans, M. and R. W. Schafer, "Lossless compression of
+              digital audio", IEEE Signal Processing Magazine, vol. 18,
+              no. 4, pp. 21-32, DOI 10.1109/79.939834, July 2001,
+              <https://ieeexplore.ieee.org/document/939834>.
+
+
+
+
+
+ 
+   [lossyWAV] Hydrogenaudio Knowledgebase, "lossyWAV", July 2021,
+              <https://wiki.hydrogenaud.io/
+              index.php?title=LossyWAV&oldid=32877>.
+
+
+
+
+
+ 
+   [MLP]      Gerzon, M. A., Craven, P. G., Stuart, J. R., Law, M. J.,
+              and R. J. Wilson, "The MLP Lossless Compression System",
+              Audio Engineering Society Conference: 17th International
+              Conference: High-Quality Audio Codin, September 1999,
+              <https://www.aes.org/e-lib/online/browse.cfm?elib=8082>.
+
+
+
+
+
+ 
+   [MusicBrainz]
+              MusicBrainz, "Tags & Variables", MusicBrainz Picard v2.10
+              documentation, <https://picard-
+              docs.musicbrainz.org/en/variables/variables.html>.
+
+
+
+
+
+ 
+   [RFC4732]  Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet
+              Denial-of-Service Considerations", RFC 4732,
+              DOI 10.17487/RFC4732, December 2006,
+              <https://www.rfc-editor.org/info/rfc4732>.
+
+
+
+
+
+ 
+   [RFC5334]  Goncalves, I., Pfeiffer, S., and C. Montgomery, "Ogg Media
+              Types", RFC 5334, DOI 10.17487/RFC5334, September 2008,
+              <https://www.rfc-editor.org/info/rfc5334>.
+
+
+
+
+
+ 
+   [RFC6716]  Valin, JM., Vos, K., and T. Terriberry, "Definition of the
+              Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716,
+              September 2012, <https://www.rfc-editor.org/info/rfc6716>.
+
+
+
+
+
+ 
+   [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>.
+
+
+
+
+
+ 
+   [Rice]     Rice, R. F. and J. R. Plaunt, "Adaptive Variable-Length
+              Coding for Efficient Compression of Spacecraft Television
+              Data", IEEE Transactions on Communication Technology, vol.
+              19, no. 6, pp. 889-897, DOI 10.1109/TCOM.1971.1090789,
+              December 1971,
+              <https://ieeexplore.ieee.org/document/1090789>.
+
+
+
+
+
+ 
+   [Robinson-TR156]
+              Robinson, T., "SHORTEN: Simple lossless and near-lossless
+              waveform compression", Cambridge University Engineering
+              Department Technical Report CUED/F-INFENG/TR.156, December
+              1994, <https://mi.eng.cam.ac.uk/reports/svr-ftp/auto-pdf/
+              robinson_tr156.pdf>.
+
+
+
+
+
+ 
+   [Shannon]  Shannon, C. E., "Communication in the Presence of Noise",
+              Proceedings of the IRE, vol. 37, no. 1, pp. 10-21,
+              DOI 10.1109/JRPROC.1949.232969, January 1949,
+              <https://ieeexplore.ieee.org/document/1697831>.
+
+
+
+
+
+ 
+   [VarLengthCode]
+              Wikipedia, "Variable-length code", April 2024,
+              <https://en.wikipedia.org/w/index.php?title=Variable-
+              length_code&oldid=1220260423>.
+
+
+
+
+
+ 
+   [Vorbis]   Xiph.Org, "Ogg Vorbis I format specification: comment
+              field and header specification",
+              <https://xiph.org/vorbis/doc/v-comment.html>.
+
+
+
+
+
+
+Appendix A. Numerical Considerations +
+
+
+
+付録A. 数値的考慮事項 +
+
+
+
+
+

+In order to maintain lossless behavior, all arithmetic used in encoding and decoding sample values must be done with integer data types to eliminate the possibility of introducing rounding errors associated with floating-point arithmetic. Use of floating-point representations in analysis (e.g., finding a good predictor or Rice parameter) is not a concern as long as the process of using the found predictor and Rice parameter to encode audio samples is implemented with only integer math. +

+
+
+

+ロスレス動作を維持するために、サンプル値のエンコードとデコードで使用されるすべての算術を整数データ型で行う必要があります。分析におけるフローティングポイント表現の使用（例：適切な予測因子またはイネパラメーターを見つける）は、見つかった予測子とイネパラメーターを使用してオーディオサンプルをエンコードするプロセスが整数数学のみで実装されている限り、懸念事項ではありません。 +

+
+
+
+
+

+Furthermore, the possibility of integer overflow can be eliminated by using data types that are large enough. Choosing a 64-bit signed data type for all arithmetic involving sample values would make sure the possibility for overflow is eliminated, but usually, smaller data types are chosen for increased performance, especially in embedded devices. This appendix provides guidelines for choosing the appropriate data type for each step of encoding and decoding FLAC files. +

+
+
+

+さらに、整数オーバーフローの可能性は、十分に大きいデータ型を使用して排除できます。サンプル値を含むすべての算術に対して64ビットの署名されたデータ型を選択すると、オーバーフローの可能性が排除されることを確認しますが、通常、特に埋め込まれたデバイスでは、パフォーマンスの向上のために小さなデータ型が選択されます。この付録は、FLACファイルをエンコードおよびデコードする各ステップに適切なデータ型を選択するためのガイドラインを提供します。 +

+
+
+
+
+

+In this appendix, signed data types are signed two's complement. +

+
+
+

+この付録では、署名されたデータ型が2つの補完に署名されています。 +

+
+
+
+
+
+A.1. Determining the Necessary Data Type Size +
+
+
+
+A.1. 必要なデータ型サイズを決定します +
+
+
+
+
+

+To find the smallest data type size that is guaranteed not to overflow for a certain sequence of arithmetic operations, the combination of values producing the largest possible result should be considered. +

+
+
+

+一連の算術演算でオーバーフローしないように保証されている最小のデータ型サイズを見つけるには、可能な最大の結果を生成する値の組み合わせを考慮する必要があります。 +

+
+
+
+
+

+For example, if two 16-bit signed integers are added, the largest possible result forms if both values are the largest number that can be represented with a 16-bit signed integer. To store the result, a signed integer data type with at least 17 bits is needed. Similarly, when adding 4 of these values, 18 bits are needed; when adding 8, 19 bits are needed, etc. In general, the number of bits necessary when adding numbers together is increased by the log base 2 of the number of values rounded up to the nearest integer. So, when adding 18 unknown values stored in 8-bit signed integers, we need a signed integer data type of at least 13 bits to store the result, as the log base 2 of 18 rounded up is 5. +

+
+
+

+たとえば、2つの16ビットの署名された整数が追加された場合、両方の値が16ビット署名整数で表すことができる最大の数値である場合、可能な最大の結果形式が追加されます。結果を保存するには、少なくとも17ビットの署名された整数データ型が必要です。同様に、これらの値のうち4つを追加する場合、18ビットが必要です。一般的に、8、19ビットを追加する場合、数値を追加するときに必要なビット数は、最寄りの整数に丸められた値の数のログベース2によって増加します。したがって、8ビットの署名された整数に保存されている18の未知の値を追加すると、結果を保存するために少なくとも13ビットの署名整数データ型が必要です。 +

+
+
+
+
+

+When multiplying two numbers, the number of bits needed for the result is the size of the first number plus the size of the second number. For example, if a 16-bit signed integer is multiplied by another 16-bit signed integer, the result needs at least 32 bits to be stored without overflowing. To show this in practice, the largest signed value that can be stored in 4 bits is -8. (-8)*(-8) is 64, which needs at least 8 bits (signed) to store. +

+
+
+

+2つの数値を掛けると、結果に必要なビット数は、最初の数字のサイズと2番目の数字のサイズです。たとえば、16ビットの署名された整数に別の16ビットの署名整数を掛けている場合、結果はオーバーフローせずに保存するために少なくとも32ビットを必要とします。これを実際に示すために、4ビットで保存できる最大の署名値は-8です。（-8）*（-8）は64で、保存するには少なくとも8ビット（署名）が必要です。 +

+
+
+
+
+
+A.2. Stereo Decorrelation +
+
+
+
+A.2. ステレオ分離 +
+
+
+
+
+

+When stereo decorrelation is used, the side channel will have one extra bit of bit depth; see Section 4.2. +

+
+
+

+Stereoの分離を使用すると、サイドチャネルには少しのビット深度があります。セクション4.2を参照してください。 +

+
+
+
+
+

+This means that while 16-bit signed integers have sufficient range to store samples from a fully decoded FLAC frame with a bit depth of 16 bits, the decoding of a side subframe in such a file will need a data type with at least 17 bits to store decoded subframe samples before undoing stereo decorrelation. +

+
+
+

+これは、16ビットの署名済み整数には、16ビットの少し深さの完全なデコードされたFLACフレームからサンプルを保存するのに十分な範囲があるが、そのようなファイルのサイドサブフレームのデコードには、少なくとも17ビットのデータ型が必要であることを意味します。ステレオ脱線を元に戻す前に、デコードされたサブフレームサンプルを保存します。 +

+
+
+
+
+

+Most FLAC decoders store decoded (subframe) samples as 32-bit values, which is sufficient for files with bit depths up to (and including) 31 bits. +

+
+
+

+ほとんどのFLACデコーダは、デコードされた（サブフレーム）サンプルを32ビット値として保存します。これは、31ビットまでのビット深度（および含有）のファイルに十分です。 +

+
+
+
+
+
+A.3. Prediction +
+
+
+
+A.3. 予測 +
+
+
+
+
+

+A prediction (which is used to calculate the residual on encoding or added to the residual to calculate the sample value on decoding) is formed by multiplying and summing preceding sample values. In order to eliminate the possibility of integer overflow, the combination of preceding sample values and predictor coefficients producing the largest possible value should be considered. +

+
+
+

+予測（エンコード時に残差を計算するために使用されるか、デコードでサンプル値を計算するために残差に追加されます）は、前のサンプル値を乗算および合計することによって形成されます。整数のオーバーフローの可能性を排除するために、先行するサンプル値と可能な最大の値を生成する予測係数の組み合わせを考慮する必要があります。 +

+
+
+
+
+

+To determine the size of the data type needed to calculate either a residual sample (on encoding) or an audio sample value (on decoding) in a fixed predictor subframe, the maximum possible value for these is calculated as described in Appendix A.1 and in the following table. For example, if a frame codes for 16-bit audio and has some form of stereo decorrelation, the subframe coding for the side channel would need 16+1+3 bits if a third-order fixed predictor is used. +

+
+
+

+固定予測サブフレームの残差サンプル（エンコード時）またはオーディオサンプル値（デコード時）のいずれかを計算するために必要なデータ型のサイズを決定するために、これらの最大値は、付録A.1および説明のように計算されます。次の表に。たとえば、フレームが16ビットオーディオをコードし、何らかの形のステレオ分離を備えている場合、サイドチャネルのサブフレームコーディングには、3次固定予測子が使用される場合は16+1+3ビットが必要です。 +

+
+
+
+
+ 
+    +=======+==============================+===============+=======+
+    | Order | Calculation of Residual      | Sample Values | Extra |
+    |       |                              | Summed        | Bits  |
+    +=======+==============================+===============+=======+
+    | 0     | a(n)                         | 1             | 0     |
+    +-------+------------------------------+---------------+-------+
+    | 1     | a(n) - a(n-1)                | 2             | 1     |
+    +-------+------------------------------+---------------+-------+
+    | 2     | a(n) - 2 * a(n-1) + a(n-2)   | 4             | 2     |
+    +-------+------------------------------+---------------+-------+
+    | 3     | a(n) - 3 * a(n-1) + 3 *      | 8             | 3     |
+    |       | a(n-2) - a(n-3)              |               |       |
+    +-------+------------------------------+---------------+-------+
+    | 4     | a(n) - 4 * a(n-1) + 6 *      | 16            | 4     |
+    |       | a(n-2) - 4 * a(n-3) + a(n-4) |               |       |
+    +-------+------------------------------+---------------+-------+
+
+                                Table 26
+
+
+
+
+
+

+Where: +

+
+
+

+ただし： +

+
+
+
+
+

+* n is the number of the sample being predicted. +

+
+
+

+* nは予測されるサンプルの数です。 +

+
+
+
+
+

+* a(n) is the sample being predicted. +

+
+
+

+* A（n）は予測されるサンプルです。 +

+
+
+
+
+

+* a(n-1) is the sample before the one being predicted, a(n-2) is the sample before that, etc. +

+
+
+

+* A（n-1）は、予測される前のサンプルであり、A（n-2）はその前のサンプルです。 +

+
+
+
+
+

+For subframes with a linear predictor, the calculation is a little more complicated. Each prediction is the sum of several multiplications. Each of these multiply a sample value with a predictor coefficient. The extra bits needed can be calculated by adding the predictor coefficient precision (in bits) to the bit depth of the audio samples. To account for the summing of these multiplications, the log base 2 of the predictor order rounded up is added. +

+
+
+

+線形予測因子を使用したサブフレームの場合、計算はもう少し複雑です。各予測は、いくつかの乗算の合計です。これらのそれぞれは、サンプル値に予測係数を掛けます。必要な追加ビットは、音声サンプルのビット深さに予測係数精度（ビット）を追加することで計算できます。これらの乗算の合計を説明するために、切り上げられた予測順のログベース2が追加されます。 +

+
+
+
+
+

+For example, if the sample bit depth of the source is 24, the current subframe encodes a side channel (see Section 4.2), the predictor order is 12, and the predictor coefficient precision is 15 bits, the minimum required size of the used signed integer data type is at least (24 + 1) + 15 + ceil(log2(12)) = 44 bits. As another example, with a side-channel subframe bit depth of 16, a predictor order of 8, and a predictor coefficient precision of 12 bits, the minimum required size of the used signed integer data type is (16 + 1) + 12 + ceil(log2(8)) = 32 bits. +

+
+
+

+たとえば、ソースのサンプルビット深度が24の場合、現在のサブフレームはサイドチャネルをエンコードし（セクション4.2を参照）、予測順序は12、予測係数精度は15ビットです。整数データ型は、少なくとも（24 + 1） + 15 + CEIL（log2（12））= 44ビットです。別の例として、16のサイドチャネルサブフレームビット深度、8の予測順、および12ビットの予測係数精度がある場合、使用されている署名された整数データ型の最小必要なサイズは（16 + 1） + 12 +ですCEIL（log2（8））= 32ビット。 +

+
+
+
+
+
+A.4. Residual +
+
+
+
+A.4. 残差 +
+
+
+
+
+

+As stated in Section 9.2.7, an encoder must make sure residual samples are representable by a 32-bit integer, signed two's complement, excluding the most negative value. As in the previous section, it is possible to calculate when residual samples already implicitly fit and when an additional check is needed. This implicit fit is achieved when residuals would fit a theoretical 31-bit signed integer, as that satisfies both of the mentioned criteria. When this implicit fit is not achieved, all residual values must be calculated and checked individually. +

+
+
+

+セクション9.2.7で述べたように、エンコーダーは、最も負の値を除く、32ビットの整数によって残留サンプルが表現できることを確認する必要があります。前のセクションと同様に、残留サンプルがすでに暗黙的に適合したときと追加のチェックが必要な時期を計算することができます。この暗黙の適合は、上記の両方の基準を満たすため、残差が理論的な31ビット署名整数に適合する場合に達成されます。この暗黙の適合が達成されない場合、すべての残差値を個別に計算してチェックする必要があります。 +

+
+
+
+
+

+For the residual of a fixed predictor, the maximum residual sample size was already calculated in the previous section. However, for a linear predictor, the prediction is shifted right by a certain amount. The number of bits needed for the residual is the number of bits calculated in the previous section, reduced by the prediction right shift, and increased by one bit to account for the subtraction of the prediction from the current sample on encoding. +

+
+
+

+固定予測子の残差については、前のセクションで最大残留サンプルサイズがすでに計算されていました。ただし、線形予測因子の場合、予測は一定の量だけシフトされます。残差に必要なビットの数は、前のセクションで計算されたビットの数であり、予測の正しいシフトによって減少し、エンコーディングに関する現在のサンプルからの予測の減算を説明するために1ビット増加しました。 +

+
+
+
+
+

+Taking the last example of the previous section, where 32 bits were needed for the prediction, the required data type size for the residual samples in case of a right shift of 10 bits would be 32 - 10 + 1 = 23 bits, which means it is not necessary to perform the aforementioned check. +

+
+
+

+予測に32ビットが必要だった前のセクションの最後の例を使用すると、10ビットの正しいシフトの場合に残留サンプルに必要なデータ型サイズは32-10 + 1 = 23ビットです。前述のチェックを実行するために必要ではありません。 +

+
+
+
+
+

+As another example, when encoding 32-bit PCM with fixed predictors, all predictor orders must be checked. While the zero-order fixed predictor is guaranteed to have residual samples that fit a 32-bit signed integer, it might produce a residual sample value that is the most negative representable value of that 32-bit signed integer. +

+
+
+

+別の例として、固定予測子を使用して32ビットPCMをエンコードする場合、すべての予測順序を確認する必要があります。ゼロオーダーの固定予測子は、32ビットの署名整数に適合する残留サンプルを持つことが保証されていますが、その32ビット署名された整数の最も負の表現可能な値である残差サンプル値を生成する可能性があります。 +

+
+
+
+
+

+Note that on decoding, while the residual sample values are limited to the aforementioned range, the predictions are not. This means that while the decoding of the residual samples can happen fully in 32-bit signed integers, decoders must be sure to execute the addition of each residual sample to its accompanying prediction with a signed integer data type that is wide enough, as with encoding. +

+
+
+

+デコード時には、残留サンプル値は前述の範囲に限定されていますが、予測はそうではないことに注意してください。つまり、残差サンプルのデコードは32ビットの署名済み整数で完全に発生する可能性がありますが、デコーダーは、エンコードと同様に、署名済みの整数データタイプを使用して、それぞれの残差サンプルを付随する予測に追加する必要があることを意味します。。 +

+
+
+
+
+
+A.5. Rice Coding +
+
+
+
+A.5. 米コーディング +
+
+
+
+
+

+When folding (i.e., zigzag encoding) the residual sample values, no extra bits are needed when the absolute value of each residual sample is first stored in an unsigned data type of the size of the last step, then doubled, and then has one subtracted depending on whether the residual sample was positive or negative. However, many implementations choose to require one extra bit of data type size so zigzag encoding can happen in one step without a cast instead of the procedure described in the previous sentence. +

+
+
+

+残留サンプル値を折りたたむ（つまり、zigzagエンコード）の場合、各残差サンプルの絶対値が最初に最後のステップのサイズの符号なしデータ型に保存され、次に2倍になり、1つが減算された場合、余分なビットは必要ありません残留サンプルが陽性かマイナスかによって異なります。ただし、多くの実装は、前の文に記載されている手順ではなく、キャストなしで1つのステップでZigzagエンコードが発生する可能性があるため、1つの追加のデータ型サイズを必要とすることを選択します。 +

+
+
+
+
+
+Appendix B. Past Format Changes +
+
+
+
+付録B. 過去の形式の変更 +
+
+
+
+
+

+This informational appendix documents the changes made to the FLAC format over the years. This information might be of use when encountering FLAC files that were made with software following the format as it was before the changes documented in this appendix. +

+
+
+

+この情報付録には、長年にわたってFLAC形式に加えられた変更が記録されています。この情報は、この付録に文書化された変更の前に形式に従ってソフトウェアで作成されたFLACファイルに遭遇する場合に使用される場合があります。 +

+
+
+
+
+

+The FLAC format was first specified in December 2000, and the bitstream format was considered frozen with the release of FLAC 1.0 (the reference encoder/decoder) in July 2001. Only changes made since this first stable release are considered in this appendix. Changes made to the FLAC streamable subset definition (see Section 7) are not considered. +

+
+
+

+FLAC形式は2000年12月に最初に指定され、BitStream形式は2001年7月にFLAC 1.0（参照エンコーダ/デコーダー）のリリースで凍結されたと見なされました。この最初の安定したリリースがこの付録で考慮されてから変更された変更のみが行われます。FLACストリーミング可能なサブセット定義（セクション7を参照）に加えられた変更は考慮されません。 +

+
+
+
+
+
+B.1. Addition of Blocking Strategy Bit +
+
+
+
+B.1. ブロッキング戦略ビットの追加 +
+
+
+
+
+

+Perhaps the largest backwards-incompatible change to the specification was published in July 2007. Before this change, variable block size streams were not explicitly marked as such by a flag bit in the frame header. A decoder had two ways to detect a variable block size stream: by comparing the minimum and maximum block sizes in the streaminfo metadata block (which are equal for a fixed block size stream) or by detecting a change of block size during a stream if a decoder did not receive a streaminfo metadata block, which could not happen at all in theory. As the meaning of the coded number in the frame header depends on whether or not a stream has a variable block size, this presented a problem: the meaning of the coded number could not be reliably determined. To fix this problem, one of the reserved bits was changed to be used as a blocking strategy bit. See also Section 9.1. +

+
+
+

+おそらく、仕様の最大の後方に取得しやすい変更は2007年7月に公開されました。この変更の前に、フレームヘッダーのフラグビットによって、可変ブロックサイズのストリームがそのように明示的にマークされていませんでした。デコーダーには、可変ブロックサイズのストリームを検出する2つの方法がありました。Streaminfoメタデータブロックの最小ブロックサイズと最大ブロックサイズ（固定ブロックサイズのストリームに等しい）を比較するか、またはストリーム中のブロックサイズの変更を検出することにより、デコーダーは、Streaminfoメタデータブロックを受け取りませんでしたが、理論的にはまったく発生することはできませんでした。フレームヘッダー内のコード化された数値の意味は、ストリームのブロックサイズが可変なかどうかに依存するため、これは問題を提示しました。コード化された数字の意味は確実に決定できませんでした。この問題を修正するために、予約されたビットの1つがブロッキング戦略ビットとして使用されるように変更されました。セクション9.1も参照してください。 +

+
+
+
+
+

+Along with the addition of a new flag, the meaning of the block size bits (see Section 9.1.1) was subtly changed. Initially, block size bits patterns 0b0001-0b0101 and 0b1000-0b1111 could only be used for fixed block size streams, while 0b0110 and 0b0111 could be used for both fixed block size and variable block size streams. With this change, these restrictions were lifted, and patterns 0b0001-0b1111 are now used for both variable block size and fixed block size streams. +

+
+
+

+新しいフラグの追加に加えて、ブロックサイズビットの意味（セクション9.1.1を参照）が微妙に変更されました。最初に、ブロックサイズビットパターン0B0001-0B0101および0B1000-0B1111は固定ブロックサイズのストリームにのみ使用できますが、0B0110と0B0111は、固定ブロックサイズと可変ブロックサイズのストリームの両方に使用できます。この変更により、これらの制限は解除され、パターン0B0001-0B1111は、可変ブロックサイズと固定ブロックサイズのストリームの両方に使用されます。 +

+
+
+
+
+
+B.2. Restriction of Encoded Residual Samples +
+
+
+
+B.2. エンコードされた残留サンプルの制限 +
+
+
+
+
+

+Another change to the specification was deemed necessary during standardization by the CELLAR Working Group of the IETF. As specified in Section 9.2.7, a limit is imposed on residual samples. This limit was not specified prior to the IETF standardization effort. However, as far as was known to the working group, no FLAC encoder at that time produced FLAC files containing residual samples exceeding this limit. This is mostly because it is very unlikely to encounter residual samples exceeding this limit when encoding 24-bit PCM, and encoding of PCM with higher bit depths was not yet implemented in any known encoder. In fact, these FLAC encoders would produce corrupt files upon being triggered to produce such residual samples, and it is unlikely any non-experimental encoder would ever do so, even when presented with crafted material. Therefore, it was not expected that existing implementations would be rendered non-compliant by this change. +

+
+
+

+IETFのセラーワーキンググループによる標準化中に、仕様に対する別の変更が必要であるとみなされました。セクション9.2.7で指定されているように、残留サンプルに制限が課されます。この制限は、IETF標準化の取り組みの前に指定されていません。ただし、ワーキンググループに知られている限り、当時のFLACエンコーダーは、この制限を超える残留サンプルを含むFLACファイルを生成しませんでした。これは主に、24ビットPCMをエンコードするときにこの制限を超える残留サンプルに遭遇する可能性が非常に低く、ビット深さの高いPCMのエンコードが既知のエンコーダーにまだ実装されていないためです。実際、これらのFLACエンコーダーは、そのような残留サンプルを生成するようにトリガーされたときに破損したファイルを生成し、作られた素材が提示されたとしても、非実験的エンコーダーがそうすることはほとんどありません。したがって、この変更により、既存の実装が非準拠になるとは予想されていませんでした。 +

+
+
+
+
+
+B.3. Addition of 5-Bit Rice Parameters +
+
+
+
+B.3. 5ビットライスパラメーターの追加 +
+
+
+
+
+

+One significant addition to the format was the residual coding method using 5-bit Rice parameters. Prior to publication of this addition in July 2007, a partitioned Rice code with 4-bit Rice parameters was the only residual coding method specified. The range offered by this coding method proved too small when encoding 24-bit PCM; therefore, a second residual coding method was specified that was identical to the first, but with 5-bit Rice parameters. +

+
+
+

+この形式への重要な追加の1つは、5ビットライスパラメーターを使用した残差コーディング方法でした。2007年7月にこの追加が公開される前に、4ビットの米パラメーターを備えた分割済み稲法が指定された唯一の残留コーディング方法でした。このコーディング方法で提供される範囲は、24ビットPCMをエンコードすると小さすぎることが判明しました。したがって、2番目の残差コーディング方法が指定され、最初の残留コードと5ビットのイネパラメーターを使用しました。 +

+
+
+
+
+
+B.4. Restriction of LPC Shift to Non-negative Values +
+
+
+
+B.4. LPCの制限は、非陰性値へのシフト +
+
+
+
+
+

+As stated in Section 9.2.6, the predictor right shift is a number signed two's complement, which MUST NOT be negative. This is because shifting a number to the right by a negative amount is undefined behavior in the C programming language standard. The intended behavior was that a positive number would be a right shift and a negative number would be a left shift. The FLAC reference encoder was changed in 2007 to not generate LPC subframes with a negative predictor right shift, as it turned out that the use of such subframes would only very rarely provide any benefit and the decoders that were already widely in use at that point were not able to handle such subframes. +

+
+
+

+セクション9.2.6で述べたように、予測因子の右シフトは、2人の補完署名数字であり、負のものであってはなりません。これは、マイナス量によって数値を右にシフトすることが、Cプログラミング言語標準で未定義の動作であるためです。意図した動作は、正の数が正しいシフトであり、負の数は左シフトになるということでした。FLACリファレンスエンコーダは2007年に変更され、ネガティブな予測子の右シフトでLPCサブフレームを生成しないように変更されました。そのようなサブフレームの使用は非常にめったに利益を提供しないことが判明し、その時点ですでに広く使用されていたデコーダーはこのようなサブフレームを処理できません。 +

+
+
+
+
+
+Appendix C. Interoperability Considerations +
+
+
+
+付録C. 相互運用性の考慮事項 +
+
+
+
+
+

+As documented in Appendix B, there have been some changes and additions to the FLAC format. Additionally, implementation of certain features of the FLAC format took many years, meaning early decoder implementations could not be tested against files with these features. Finally, many lower-quality FLAC decoders only implement just enough features required for playback of the most common FLAC files. +

+
+
+

+付録Bに文書化されているように、FLAC形式にいくつかの変更と追加がありました。さらに、FLAC形式の特定の機能の実装には何年もかかりました。つまり、これらの機能を備えたファイルに対して初期のデコーダー実装をテストできませんでした。最後に、多くの低品質のFLACデコーダは、最も一般的なFLACファイルの再生に必要な十分な機能のみを実装します。 +

+
+
+
+
+

+This appendix provides some considerations for encoder implementations aiming to create highly compatible files. As this topic is one that might change after this document is published, consult [FLAC-wiki-interoperability] for more up-to-date information. +

+
+
+

+この付録は、互換性の高いファイルを作成することを目的としたエンコーダーの実装に関するいくつかの考慮事項を提供します。このトピックは、このドキュメントが公開された後に変更される可能性のあるトピックであるため、最新情報については[FLAC-Wikiインターパラリティ]を参照してください。 +

+
+
+
+
+
+C.1. Features outside of the Streamable Subset +
+
+
+
+C.1. ストリーミング可能なサブセットの外側の機能 +
+
+
+
+
+

+As described in Section 7, FLAC specifies a subset of its capabilities as the FLAC streamable subset. Certain decoders may choose to only decode FLAC files conforming to the limitations imposed by the streamable subset. Therefore, maximum compatibility with decoders is achieved when the limitations of the FLAC streamable subset are followed when creating FLAC files. +

+
+
+

+セクション7で説明されているように、FLACはその機能のサブセットをFLACストリーミング可能なサブセットとして指定します。特定のデコーダは、ストリーミング可能なサブセットによって課される制限に準拠したFLACファイルのみをデコードすることを選択できます。したがって、FLACファイルを作成するときにFLACストリーミング可能なサブセットの制限が続くと、デコーダーとの最大互換性が達成されます。 +

+
+
+
+
+
+C.2. Variable Block Size +
+
+
+
+C.2. 可変ブロックサイズ +
+
+
+
+
+

+Because it is often difficult to find the optimal arrangement of block sizes for maximum compression, most encoders choose to create files with a fixed block size. Because of this, many decoder implementations receive minimal use when handling variable block size streams, and this can reveal bugs or reveal that implementations do not decode them at all. Furthermore, as explained in Appendix B.1, there have been some changes to the way variable block size streams are encoded. Because of this, maximum compatibility with decoders is achieved when FLAC files are created using fixed block size streams. +

+
+
+

+最大の圧縮のためにブロックサイズの最適な配置を見つけることはしばしば困難であるため、ほとんどのエンコーダは固定ブロックサイズのファイルを作成することを選択します。このため、多くのデコーダーの実装は、可変ブロックサイズのストリームを処理するときに最小限の使用を受けます。これにより、バグが明らかになったり、実装がそれらをデコードしないことを明らかにします。さらに、付録B.1で説明したように、可変ブロックサイズのストリームがエンコードされる方法にいくつかの変更がありました。このため、FLACファイルが固定ブロックサイズのストリームを使用して作成されると、デコーダーとの最大互換性が達成されます。 +

+
+
+
+
+
+C.3. 5-Bit Rice Parameters +
+
+
+
+C.3. 5ビットライスパラメーター +
+
+
+
+
+

+As the addition of the coding method using 5-bit Rice parameters, as described in Appendix B.3, occurred quite a few years after the FLAC format was first introduced, some early decoders might not be able to decode files containing such Rice parameters. The introduction of this was specifically aimed at improving compression of 24-bit PCM audio, and compression of 16-bit PCM audio only rarely benefits from using 5-bit Rice parameters. Therefore, maximum compatibility with decoders is achieved when FLAC files containing audio with a bit depth of 16 bits or less are created without any use of 5-bit Rice parameters. +

+
+
+

+付録B.3で説明されているように、5ビットイネパラメーターを使用したコーディング法の追加は、FLAC形式が最初に導入されてから数年後に発生したため、一部の初期デコーダはそのようなイネパラメーターを含むファイルをデコードできない可能性があります。これの導入は、24ビットPCMオーディオの圧縮を改善することを特に目的としており、16ビットPCMオーディオの圧縮は、5ビットライスパラメーターを使用することではめったに有益ではありません。したがって、5ビットライスパラメーターを使用せずに16ビット以下の少し深さのオーディオを含むFLACファイルが作成されると、デコーダーとの最大互換性が達成されます。 +

+
+
+
+
+
+C.4. Rice Escape Code +
+
+
+
+C.4. ライスエスケープコード +
+
+
+
+
+

+Escaped Rice partitions are seldom used, as it turned out their use provides only a very small compression improvement. As many encoders do not use these by default or are not capable of producing them at all, it is likely that many decoder implementations are not able to decode them correctly. Therefore, maximum compatibility with decoders is achieved when FLAC files are created without any use of escaped Rice partitions. +

+
+
+

+脱出した米のパーティションはめったに使用されません。それは、それらの使用が非常に小さな圧縮改善のみを提供することが判明したためです。多くのエンコーダーはデフォルトでこれらを使用していないか、まったく生成できないため、多くのデコーダー実装では正しくデコードできない可能性があります。したがって、脱出されたライスパーティションを使用せずにFLACファイルを作成すると、デコーダーとの最大互換性が達成されます。 +

+
+
+
+
+
+C.5. Uncommon Block Size +
+
+
+
+C.5. まれなブロックサイズ +
+
+
+
+
+

+For unknown reasons, some decoders have chosen to support only common block sizes for all but the last block of a stream. Therefore, maximum compatibility with decoders is achieved when creating FLAC files using common block sizes, as listed in Section 9.1.1, for all but the last block of a stream. +

+
+
+

+不明な理由で、一部のデコーダーは、ストリームの最後のブロックを除くすべてのすべての一般的なブロックサイズのみをサポートすることを選択しています。したがって、ストリームの最後のブロックを除くすべてのセクション9.1.1にリストされているように、一般的なブロックサイズを使用してFLACファイルを作成するときにデコーダーとの最大互換性が達成されます。 +

+
+
+
+
+
+C.6. Uncommon Bit Depth +
+
+
+
+C.6. 珍しいビットの深さ +
+
+
+
+
+

+Most audio is stored in bit depths that are a whole number of bytes, e.g., 8, 16, or 24 bits. However, there is audio with different bit depths. A few examples: +

+
+
+

+ほとんどのオーディオは、たとえば8、16、または24ビットなどのバイトのビット深さで保存されます。ただし、ビットの深さが異なるオーディオがあります。いくつかの例： +

+
+
+
+
+

+* DVD-Audio has the possibility to store 20-bit PCM audio. +

+
+
+

+* DVD-Audioには、20ビットのPCMオーディオを保存する可能性があります。 +

+
+
+
+
+

+* DAT and DV can store 12-bit PCM audio. +

+
+
+

+* DATとDVは、12ビットPCMオーディオを保存できます。 +

+
+
+
+
+

+* NICAM-728 samples at 14 bits, which is companded to 10 bits. +

+
+
+

+* NICAM-728は14ビットでサンプルされ、10ビットに互換性があります。 +

+
+
+
+
+

+* 8-bit µ-law can be losslessly converted to 14-bit (Linear) PCM. +

+
+
+

+* 8ビットµ-lawは、14ビット（線形）PCMに損失を無効に変換できます。 +

+
+
+
+
+

+* 8-bit A-law can be losslessly converted to 13-bit (Linear) PCM. +

+
+
+

+* 8ビットA-Lawは、13ビット（線形）PCMに損失を無効に変換できます。 +

+
+
+
+
+

+The FLAC format can contain these bit depths directly, but because they are uncommon, some decoders are not able to process the resulting files correctly. It is possible to store these formats in a FLAC file with a more common bit depth without sacrificing compression by padding each sample with zero bits to a bit depth that is a whole byte. The FLAC format can efficiently compress these wasted bits. See Section 9.2.2 for details. +

+
+
+

+FLAC形式にはこれらのビットの深さを直接含めることができますが、それらは珍しいため、一部のデコーダは結果のファイルを正しく処理できません。これらの形式は、各サンプルをゼロビットでパディングして、バイト全体であるビット深度にパディングすることにより、より一般的なビット深度のFLACファイルに保存することができます。FLAC形式は、これらの無駄なビットを効率的に圧縮できます。詳細については、セクション9.2.2を参照してください。 +

+
+
+
+
+

+Therefore, maximum compatibility with decoders is achieved when FLAC files are created by padding samples of such audio with zero bits to the bit depth that is the next whole number of bytes. +

+
+
+

+したがって、次のバイトのビット深さまでビットゼロのビットを持つこのようなオーディオのサンプルをパディングすることによってFLACファイルが作成されると、デコーダーとの最大互換性が達成されます。 +

+
+
+
+
+

+In cases where the original signal is already padded, this operation cannot be reversed losslessly without knowing the original bit depth. To leave no ambiguity, the original bit depth needs to be stored, for example, in a Vorbis comment field or by storing the header of the original file. The choice of a suitable method is left to the implementor. +

+
+
+

+元の信号が既にパッドが付けられている場合、この操作は、元のビットの深さを知らなくても損失を無効にすることはできません。あいまいさを残さないには、元のビット深度を、たとえば、Vorbisのコメントフィールドまたは元のファイルのヘッダーを保存して保存する必要があります。適切な方法の選択は、実装者に任されています。 +

+
+
+
+
+

+Besides audio with a "non-whole byte" bit depth, some decoder implementations have chosen to only accept FLAC files coding for PCM audio with a bit depth of 16 bits. Many implementations support bit depths up to 24 bits, but no higher. Consult [FLAC-wiki-interoperability] for more up-to-date information. +

+
+
+

+「非wholeバイト」ビットの深さを備えたオーディオに加えて、一部のデコーダー実装は、16ビットの深さでPCMオーディオをコーディングするFLACファイルのみを受け入れるように選択されています。多くの実装は、最大24ビットまでのビットの深さをサポートしていますが、高くはありません。最新情報については、[FLAC-Wiki-interoperability]を参照してください。 +

+
+
+
+
+
+C.7. Multi-Channel Audio and Uncommon Sample Rates +
+
+
+
+C.7. マルチチャネルオーディオおよび珍しいサンプルレート +
+
+
+
+
+

+Many FLAC audio players are unable to render multi-channel audio or audio with an uncommon sample rate. While this is not a concern specific to the FLAC format, it is of note when requiring maximum compatibility with decoders. Unlike the previously mentioned interoperability considerations, this is one where compatibility cannot be improved without sacrificing the lossless nature of the FLAC format. +

+
+
+

+多くのFLACオーディオプレーヤーは、珍しいサンプルレートでマルチチャネルオーディオまたはオーディオをレンダリングすることができません。これはFLAC形式に固有の懸念ではありませんが、デコーダーとの最大の互換性が必要な場合は注目に値します。前述の相互運用性の考慮事項とは異なり、これはFLAC形式のロスレス性を犠牲にせずに互換性を改善できない場合です。 +

+
+
+
+
+

+From a non-exhaustive inquiry, it seems that a non-negligible number of players, especially hardware players, do not support audio with 3 or more channels or sample rates other than those considered common; see Section 9.1.2. +

+
+
+

+網羅的ではない問い合わせから、非交渉不可能な数のプレーヤー、特にハードウェアプレーヤーは、一般的と見なされるもの以外の3つ以上のチャネルまたはサンプルレートでオーディオをサポートしていないようです。セクション9.1.2を参照してください。 +

+
+
+
+
+

+For those players that do support and are able to render multi-channel audio, many do not parse and use the WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag (see Section 8.6.2). This is also an interoperability consideration because compatibility cannot be improved without sacrificing the lossless nature of the FLAC format. +

+
+
+

+サポートし、マルチチャネルオーディオをレンダリングできるプレーヤーの場合、多くは波形Xtensible_channel_maskタグを解析して使用しません（セクション8.6.2を参照）。これは、FLAC形式の損失のない性質を犠牲にせずに互換性を改善できないため、相互運用性の考慮事項でもあります。 +

+
+
+
+
+
+C.8. Changing Audio Properties Mid-Stream +
+
+
+
+C.8. オーディオプロパティの変更中間ストリーム +
+
+
+
+
+

+Each FLAC frame header stores the audio sample rate, number of bits per sample, and number of channels independently of the streaminfo metadata block and other frame headers. This was done to permit multicasting of FLAC files, but it also allows these properties to change mid-stream. However, many FLAC decoders do not handle such changes, as few other formats are capable of holding such streams and changing playback properties during playback is often not possible without interrupting playback. Also, as explained in Section 9, using this feature of FLAC results in various practical problems. +

+
+
+

+各FLACフレームヘッダーは、オーディオサンプルレート、サンプルあたりのビット数、およびStreaminfoメタデータブロックおよびその他のフレームヘッダーとは無関係にチャネルの数を保存します。これは、FLACファイルのマルチキャストを許可するために行われましたが、これらのプロパティが中間ストリームを変更することもできます。ただし、多くのFLACデコーダーはそのような変更を処理しません。再生中にそのようなストリームを保持し、再生プロパティを変更することができる他の形式はほとんどないため、再生を中断することなく不可能です。また、セクション9で説明されているように、FLACのこの機能を使用すると、さまざまな実用的な問題が発生します。 +

+
+
+
+
+

+However, even when storing an audio stream with changing properties in FLAC encapsulated in a container capable of handling such changes, as recommended in Section 9, many decoders are not able to decode such a stream correctly. Therefore, maximum compatibility with decoders is achieved when FLAC files are created with a single set of audio properties, in which the properties coded in the streaminfo metadata block (see Section 8.2) and the properties coded in all frame headers (see Section 9.1) are the same. This can be achieved by splitting up an input stream with changing audio properties at the points where these properties change into separate streams or files. +

+
+
+

+ただし、セクション9で推奨されるように、このような変更を処理できるコンテナにカプセル化されたFLACのプロパティの変更を伴うオーディオストリームを保存する場合でも、多くのデコーダーはそのようなストリームを正しくデコードできません。したがって、FLACファイルが単一のオーディオプロパティセットで作成された場合、Decodersとの最大互換性が達成されます。このプロパティでは、Streaminfoメタデータブロックにコード化されたプロパティ（セクション8.2を参照）と、すべてのフレームヘッダーでコーディングされたプロパティ（セクション9.1を参照）が作成されます。同じ。これは、これらのプロパティが個別のストリームまたはファイルに変更されるポイントで、オーディオプロパティの変更で入力ストリームを分割することで実現できます。 +

+
+
+
+
+
+Appendix D. Examples +
+
+
+
+付録D. 例 +
+
+
+
+
+

+This informational appendix contains short examples of FLAC files that are decoded step by step. These examples provide a more engaging way to understand the FLAC format than the formal specification. The text explaining these examples assumes the reader has at least cursorily read the specification and that the reader refers to the specification for explanation of the terminology used. These examples mostly focus on the layout of several metadata blocks, subframe types, and the implications of certain aspects (e.g., wasted bits and stereo decorrelation) on this layout. +

+
+
+

+この情報付録には、段階的にデコードされたFLACファイルの短い例が含まれています。これらの例は、正式な仕様よりもFLAC形式を理解するためのより魅力的な方法を提供します。これらの例を説明するテキストは、読者が少なくとも仕様を大まかに読んでおり、読者が使用された用語の説明の仕様を参照していることを前提としています。これらの例は、主に、いくつかのメタデータブロック、サブフレームタイプのレイアウト、およびこのレイアウトの特定の側面（無駄なビットやステレオの切り離関連）の意味に焦点を当てています。 +

+
+
+
+
+

+The examples feature files generated by various FLAC encoders. These are presented in hexadecimal or binary format, followed by tables and text referring to various features by their starting bit positions in these representations. Each starting position (shortened to "start" in the tables) is a hexadecimal byte position and a start bit within that byte, separated by a plus sign. Counts for these start at zero. For example, a feature starting at the 3rd bit of the 17th byte is referred to as starting at 0x10+2. The files that are explored in these examples can be found at [FLAC-specification-github]. +

+
+
+

+この例は、さまざまなFLACエンコーダーによって生成されたファイルを機能させます。これらは16進形式またはバイナリ形式で提示され、次にこれらの表現での開始ビット位置によるさまざまな機能を参照するテーブルとテキストが続きます。各開始位置（テーブル内の「開始」に短縮）は、六分位バイトの位置であり、そのバイト内のスタートビットで、プラス記号で区切られています。これらのカウントはゼロで開始します。たとえば、17番目のバイトの3番目のビットから始まる機能は、0x10+2から始まると呼ばれます。これらの例で調査されているファイルは、[FLAC仕様-Github]にあります。 +

+
+
+
+
+

+All data in this appendix has been thoroughly verified. However, as this appendix is informational, if any information here conflicts with statements in the formal specification, the latter takes precedence. +

+
+
+

+この付録のすべてのデータは徹底的に検証されています。ただし、この付録は情報提供であるため、ここでの情報が正式な仕様の声明と矛盾する場合、後者は優先されます。 +

+
+
+
+
+
+D.1. Decoding Example 1 +
+
+
+
+D.1. デコード例1 +
+
+
+
+
+

+This very short example FLAC file codes for PCM audio that has two channels, each containing one sample. The focus of this example is on the essential parts of a FLAC file. +

+
+
+

+この非常に短い例FLACファイルは、2つのチャネルがあり、それぞれに1つのサンプルが含まれているPCMオーディオのコードをコードしています。この例の焦点は、FLACファイルの重要な部分にあります。 +

+
+
+
+
+
+D.1.1. Example File 1 in Hexadecimal Representation +
+
+
+
+D.1.1. 16進表現の例ファイル1 +
+
+
+
+
+ 
+   00000000: 664c 6143 8000 0022 1000 1000  fLaC..."....
+   0000000c: 0000 0f00 000f 0ac4 42f0 0000  ........B...
+   00000018: 0001 3e84 b418 07dc 6903 0758  ..>.....i..X
+   00000024: 6a3d ad1a 2e0f fff8 6918 0000  j=......i...
+   00000030: bf03 58fd 0312 8baa 9a         ..X......
+
+
+
+
+
+
+D.1.2. Example File 1 in Binary Representation +
+
+
+
+D.1.2. バイナリ表現の例ファイル1 +
+
+
+
+
+ 
+   00000000: 01100110 01001100 01100001 01000011  fLaC
+   00000004: 10000000 00000000 00000000 00100010  ..."
+   00000008: 00010000 00000000 00010000 00000000  ....
+   0000000c: 00000000 00000000 00001111 00000000  ....
+   00000010: 00000000 00001111 00001010 11000100  ....
+   00000014: 01000010 11110000 00000000 00000000  B...
+   00000018: 00000000 00000001 00111110 10000100  ..>.
+   0000001c: 10110100 00011000 00000111 11011100  ....
+   00000020: 01101001 00000011 00000111 01011000  i..X
+   00000024: 01101010 00111101 10101101 00011010  j=..
+   00000028: 00101110 00001111 11111111 11111000  ....
+   0000002c: 01101001 00011000 00000000 00000000  i...
+   00000030: 10111111 00000011 01011000 11111101  ..X.
+   00000034: 00000011 00010010 10001011 10101010  ....
+   00000038: 10011010
+
+
+
+
+
+
+D.1.3. Signature and Streaminfo +
+
+
+
+D.1.3. 署名とStreaminfo +
+
+
+
+
+

+The first 4 bytes of the file contain the fLaC file signature. Directly following it is a metadata block. The signature and the first metadata block header are broken down in the following table. +

+
+
+

+ファイルの最初の4バイトには、FLACファイルの署名が含まれています。直接続くのはメタデータブロックです。署名と最初のメタデータブロックヘッダーは、次の表に分解されます。 +

+
+
+
+
+ 
+        +========+=========+============+===========================+
+        | Start  | Length  | Contents   | Description               |
+        +========+=========+============+===========================+
+        | 0x00+0 | 4 bytes | 0x664C6143 | fLaC                      |
+        +--------+---------+------------+---------------------------+
+        | 0x04+0 | 1 bit   | 0b1        | Last metadata block       |
+        +--------+---------+------------+---------------------------+
+        | 0x04+1 | 7 bits  | 0b0000000  | Streaminfo metadata block |
+        +--------+---------+------------+---------------------------+
+        | 0x05+0 | 3 bytes | 0x000022   | Length of 34 bytes        |
+        +--------+---------+------------+---------------------------+
+
+                                   Table 27
+
+
+
+
+
+

+As the header indicates that this is the last metadata block, the position of the first audio frame can now be calculated as the position of the first byte after the metadata block header + the length of the block, i.e., 8+34 = 42 or 0x2a. Thus, 0x2a indeed contains the frame sync code for fixed block size streams -- 0xfff8. +

+
+
+

+ヘッダーはこれが最後のメタデータブロックであることを示しているため、最初のオーディオフレームの位置は、メタデータブロックヘッダー +ブロックの長さ、つまり8 + 34 = 42または0x2a。したがって、0x2aには、固定ブロックサイズストリームのフレーム同期コード-0xfff8が含まれています。 +

+
+
+
+
+

+The streaminfo metadata block contents are broken down in the following table. +

+
+
+

+Streaminfoメタデータブロックの内容は、次の表に分解されます。 +

+
+
+
+
+ 
++========+==========+====================+==========================+
+| Start  | Length   | Contents           | Description              |
++========+==========+====================+==========================+
+| 0x08+0 | 2 bytes  | 0x1000             | Min. block size 4096     |
++--------+----------+--------------------+--------------------------+
+| 0x0a+0 | 2 bytes  | 0x1000             | Max. block size 4096     |
++--------+----------+--------------------+--------------------------+
+| 0x0c+0 | 3 bytes  | 0x00000f           | Min. frame size 15 bytes |
++--------+----------+--------------------+--------------------------+
+| 0x0f+0 | 3 bytes  | 0x00000f           | Max. frame size 15 bytes |
++--------+----------+--------------------+--------------------------+
+| 0x12+0 | 20 bits  | 0x0ac4, 0b0100     | Sample rate 44100 hertz  |
++--------+----------+--------------------+--------------------------+
+| 0x14+4 | 3 bits   | 0b001              | 2 channels               |
++--------+----------+--------------------+--------------------------+
+| 0x14+7 | 5 bits   | 0b01111            | Sample bit depth 16      |
++--------+----------+--------------------+--------------------------+
+| 0x15+4 | 36 bits  | 0b0000, 0x00000001 | Total no. of samples 1   |
++--------+----------+--------------------+--------------------------+
+| 0x1a   | 16       | (...)              | MD5 checksum             |
+|        | bytes    |                    |                          |
++--------+----------+--------------------+--------------------------+
+
+                               Table 28
+
+
+
+
+
+

+The minimum and maximum block sizes are both 4096. This was apparently the block size the encoder planned to use, but as only 1 interchannel sample was provided, no frames with 4096 samples are actually present in this file. +

+
+
+

+最小および最大ブロックサイズはどちらも4096です。これは明らかにエンコーダーが使用する予定のブロックサイズでしたが、1つのインターチャネルサンプルのみが提供されたため、このファイルには4096サンプルのフレームは実際にはありません。 +

+
+
+
+
+

+Note that anywhere a number of samples is mentioned (block size, total number of samples, sample rate), interchannel samples are meant. +

+
+
+

+多数のサンプルが言及されている場所（ブロックサイズ、サンプルの総数、サンプルレート）、インターチャネルサンプルが意味されることに注意してください。 +

+
+
+
+
+

+The MD5 checksum (starting at 0x1a) is 0x3e84 b418 07dc 6903 0758 6a3d ad1a 2e0f. This will be validated after decoding the samples. +

+
+
+

+MD5チェックサム（0x1aから始まる）は0x3E84 B418 07DC 6903 0758 6A3D AD1A 2E0Fです。これは、サンプルをデコードした後に検証されます。 +

+
+
+
+
+
+D.1.4. Audio Frames +
+
+
+
+D.1.4. オーディオフレーム +
+
+
+
+
+

+The frame header starts at position 0x2a and is broken down in the following table. +

+
+
+

+フレームヘッダーは位置0x2aから始まり、次の表で分解されます。 +

+
+
+
+
+ 
+          +========+=========+=================+===================+
+          | Start  | Length  | Contents        | Description       |
+          +========+=========+=================+===================+
+          | 0x2a+0 | 15 bits | 0xff, 0b1111100 | Frame sync        |
+          +--------+---------+-----------------+-------------------+
+          | 0x2b+7 | 1 bit   | 0b0             | Blocking strategy |
+          +--------+---------+-----------------+-------------------+
+          | 0x2c+0 | 4 bits  | 0b0110          | 8-bit block size  |
+          |        |         |                 | further down      |
+          +--------+---------+-----------------+-------------------+
+          | 0x2c+4 | 4 bits  | 0b1001          | Sample rate 44.1  |
+          |        |         |                 | kHz               |
+          +--------+---------+-----------------+-------------------+
+          | 0x2d+0 | 4 bits  | 0b0001          | Stereo, no        |
+          |        |         |                 | decorrelation     |
+          +--------+---------+-----------------+-------------------+
+          | 0x2d+4 | 3 bits  | 0b100           | Bit depth 16 bits |
+          +--------+---------+-----------------+-------------------+
+          | 0x2d+7 | 1 bit   | 0b0             | Mandatory 0 bit   |
+          +--------+---------+-----------------+-------------------+
+          | 0x2e+0 | 1 byte  | 0x00            | Frame number 0    |
+          +--------+---------+-----------------+-------------------+
+          | 0x2f+0 | 1 byte  | 0x00            | Block size 1      |
+          +--------+---------+-----------------+-------------------+
+          | 0x30+0 | 1 byte  | 0xbf            | Frame header CRC  |
+          +--------+---------+-----------------+-------------------+
+
+                                   Table 29
+
+
+
+
+
+

+As the stream is a fixed block size stream, the number at 0x2e contains a frame number. Because the value is smaller than 128, only 1 byte is used for the encoding. +

+
+
+

+ストリームは固定ブロックサイズのストリームであるため、0x2Eの数にはフレーム番号が含まれています。値は128より小さいため、エンコードに使用されるのは1バイトのみです。 +

+
+
+
+
+

+At byte 0x31, the first subframe starts, which is broken down in the following table. +

+
+
+

+BYTE 0x31では、最初のサブフレームが開始されます。これは、次の表で分解されます。 +

+
+
+
+
+ 
+      +========+=========+================+=========================+
+      | Start  | Length  | Contents       | Description             |
+      +========+=========+================+=========================+
+      | 0x31+0 | 1 bit   | 0b0            | Mandatory 0 bit         |
+      +--------+---------+----------------+-------------------------+
+      | 0x31+1 | 6 bits  | 0b000001       | Verbatim subframe       |
+      +--------+---------+----------------+-------------------------+
+      | 0x31+7 | 1 bit   | 0b1            | Wasted bits used        |
+      +--------+---------+----------------+-------------------------+
+      | 0x32+0 | 2 bits  | 0b01           | 2 wasted bits used      |
+      +--------+---------+----------------+-------------------------+
+      | 0x32+2 | 14 bits | 0b011000, 0xfd | 14-bit unencoded sample |
+      +--------+---------+----------------+-------------------------+
+
+                                  Table 30
+
+
+
+
+
+

+As the wasted bits flag is 1 in this subframe, a unary-coded number follows. Starting at 0x32, we see 0b01, which unary codes for 1, meaning that this subframe uses 2 wasted bits. +

+
+
+

+このサブフレームの無駄なビットフラグは1であるため、統一コードされた数字が続きます。0x32から、1をコードする0B01が表示されます。つまり、このサブフレームは2つの無駄なビットを使用しています。 +

+
+
+
+
+

+As this is a verbatim subframe, the subframe only contains unencoded sample values. With a block size of 1, it contains only a single sample. The bit depth of the audio is 16 bits, but as the subframe header signals the use of 2 wasted bits, only 14 bits are stored. As no stereo decorrelation is used, a bit depth increase for the side channel is not applicable. So, the next 14 bits (starting at position 0x32+2) contain the unencoded sample coded big-endian, signed two's complement. The value reads 0b011000 11111101, or 6397. This value needs to be shifted left by 2 bits to account for the wasted bits. The value is then 0b011000 11111101 00, or 25588. +

+
+
+

+これは逐語的なサブフレームであるため、サブフレームにはエンコードされていないサンプル値のみが含まれています。ブロックサイズが1の場合、単一のサンプルのみが含まれています。オーディオのビット深度は16ビットですが、サブフレームヘッダーが2つの無駄なビットの使用を通知するため、14ビットのみが保存されます。ステレオの分離は使用されないため、サイドチャネルの深さの増加は適用されません。したがって、次の14ビット（位置0x32+2から始まる）には、エンコードされていないサンプルコード化されたビッグエンディアンが含まれています。値は0B011000 11111101、つまり6397を読み取ります。この値は、無駄なビットを考慮して2ビットを残してシフトする必要があります。値は0B011000 11111101 00、つまり25588です。 +

+
+
+
+
+

+The second subframe starts at 0x34 and is broken down in the following table. +

+
+
+

+2番目のサブフレームは0x34から始まり、次の表で分解されます。 +

+
+
+
+
+ 
+        +========+=========+==============+=========================+
+        | Start  | Length  | Contents     | Description             |
+        +========+=========+==============+=========================+
+        | 0x34+0 | 1 bit   | 0b0          | Mandatory 0 bit         |
+        +--------+---------+--------------+-------------------------+
+        | 0x34+1 | 6 bits  | 0b000001     | Verbatim subframe       |
+        +--------+---------+--------------+-------------------------+
+        | 0x34+7 | 1 bit   | 0b1          | Wasted bits used        |
+        +--------+---------+--------------+-------------------------+
+        | 0x35+0 | 4 bits  | 0b0001       | 4 wasted bits used      |
+        +--------+---------+--------------+-------------------------+
+        | 0x35+4 | 12 bits | 0b0010, 0x8b | 12-bit unencoded sample |
+        +--------+---------+--------------+-------------------------+
+
+                                   Table 31
+
+
+
+
+
+

+The wasted bits flag is also one, but the unary-coded number that follows it is 4 bits long, indicating the use of 4 wasted bits. This means the sample is stored in 12 bits. The sample value is 0b0010 10001011, or 651. This value now has to be shifted left by 4 bits, i.e., 0b0010 10001011 0000, or 10416. +

+
+
+

+無駄なビットフラグも1つですが、それに続く単位コードされた数字は4ビットで、4ビットの使用を示しています。これは、サンプルが12ビットで保存されることを意味します。サンプル値は0B0010 10001011、または651です。この値は、4ビット、つまり0B0010 10001011 0000、つまり10416だけシフトする必要があります。 +

+
+
+
+
+

+At this point, we would undo stereo decorrelation if that was applicable. +

+
+
+

+この時点で、それが該当する場合は、ステレオの分離を元に戻します。 +

+
+
+
+
+

+As the last subframe ends byte-aligned, no padding bits follow it. The next 2 bytes, starting at 0x38, contain the frame CRC. As this is the only frame in the file, the file ends with the CRC. +

+
+
+

+最後のサブフレームがバイトアラインで終了すると、パディングビットはそれに続きません。0x38から始まる次の2バイトには、フレームCRCが含まれています。これがファイル内の唯一のフレームであるため、ファイルはCRCで終了します。 +

+
+
+
+
+

+To validate the MD5 checksum, we line up the samples interleaved, byte-aligned, little-endian, signed two's complement. The first sample, with value 25588, translates to 0xf463, and the second sample, with value 10416, translates to 0xb028. When computing the MD5 checksum with 0xf463b028 as input, we get the MD5 checksum found in the header, so decoding was lossless. +

+
+
+

+MD5チェックサムを検証するために、インターリーブ、バイトアリード、リトルエンディアンのサンプルを並べ、2人の補完に署名しました。値25588の最初のサンプルは0xF463に変換され、値10416の2番目のサンプルは0xB028に変換されます。入力として0xF463B028でMD5チェックサムを計算すると、ヘッダーにMD5チェックサムが見つかりますので、デコードはロスレスでした。 +

+
+
+
+
+
+D.2. Decoding Example 2 +
+
+
+
+D.2. デコード例2 +
+
+
+
+
+

+This FLAC file is larger than the first example, but still contains very little audio. The focus of this example is on decoding a subframe with a fixed predictor and a coded residual, but it also contains a very short seek table, a Vorbis comment metadata block, and a padding metadata block. +

+
+
+

+このFLACファイルは最初の例よりも大きいですが、オーディオはほとんど含まれていません。この例の焦点は、固定予測子とコード化された残差を使用したサブフレームのデコードにありますが、非常に短いシークテーブル、Vorbisコメントメタデータブロック、およびパディングメタデータブロックも含まれています。 +

+
+
+
+
+
+D.2.1. Example File 2 in Hexadecimal Representation +
+
+
+
+D.2.1. 16進表現の例ファイル2 +
+
+
+
+
+ 
+   00000000: 664c 6143 0000 0022 0010 0010  fLaC..."....
+   0000000c: 0000 1700 0044 0ac4 42f0 0000  .....D..B...
+   00000018: 0013 d5b0 5649 75e9 8b8d 8b93  ....VIu.....
+   00000024: 0422 757b 8103 0300 0012 0000  ."u{........
+   00000030: 0000 0000 0000 0000 0000 0000  ............
+   0000003c: 0000 0010 0400 003a 2000 0000  .......: ...
+   00000048: 7265 6665 7265 6e63 6520 6c69  reference li
+   00000054: 6246 4c41 4320 312e 332e 3320  bFLAC 1.3.3
+   00000060: 3230 3139 3038 3034 0100 0000  20190804....
+   0000006c: 0e00 0000 5449 544c 453d d7a9  ....TITLE=..
+   00000078: d79c d795 d79d 8100 0006 0000  ............
+   00000084: 0000 0000 fff8 6998 000f 9912  ......i.....
+   00000090: 0867 0162 3d14 4299 8f5d f70d  .g.b=.B..]..
+   0000009c: 6fe0 0c17 caeb 2100 0ee7 a77a  o.....!....z
+   000000a8: 24a1 590c 1217 b603 097b 784f  $.Y......{xO
+   000000b4: aa9a 33d2 85e0 70ad 5b1b 4851  ..3...p.[.HQ
+   000000c0: b401 0d99 d2cd 1a68 f1e6 b810  .......h....
+   000000cc: fff8 6918 0102 a402 c382 c40b  ..i.........
+   000000d8: c14a 03ee 48dd 03b6 7c13 30    .J..H...|.0
+
+
+
+
+
+
+D.2.2. Example File 2 in Binary Representation (Only Audio Frames) +
+
+
+
+D.2.2. バイナリ表現の例ファイル2（オーディオフレームのみ） +
+
+
+
+
+ 
+   00000088: 11111111 11111000 01101001 10011000  ..i.
+   0000008c: 00000000 00001111 10011001 00010010  ....
+   00000090: 00001000 01100111 00000001 01100010  .g.b
+   00000094: 00111101 00010100 01000010 10011001  =.B.
+   00000098: 10001111 01011101 11110111 00001101  .]..
+   0000009c: 01101111 11100000 00001100 00010111  o...
+   000000a0: 11001010 11101011 00100001 00000000  ..!.
+   000000a4: 00001110 11100111 10100111 01111010  ...z
+   000000a8: 00100100 10100001 01011001 00001100  $.Y.
+   000000ac: 00010010 00010111 10110110 00000011  ....
+   000000b0: 00001001 01111011 01111000 01001111  .{xO
+   000000b4: 10101010 10011010 00110011 11010010  ..3.
+   000000b8: 10000101 11100000 01110000 10101101  ..p.
+   000000bc: 01011011 00011011 01001000 01010001  [.HQ
+   000000c0: 10110100 00000001 00001101 10011001  ....
+   000000c4: 11010010 11001101 00011010 01101000  ...h
+   000000c8: 11110001 11100110 10111000 00010000  ....
+   000000cc: 11111111 11111000 01101001 00011000  ..i.
+   000000d0: 00000001 00000010 10100100 00000010  ....
+   000000d4: 11000011 10000010 11000100 00001011  ....
+   000000d8: 11000001 01001010 00000011 11101110  .J..
+   000000dc: 01001000 11011101 00000011 10110110  H...
+   000000e0: 01111100 00010011 00110000           |.0
+
+
+
+
+
+
+D.2.3. Streaminfo Metadata Block +
+
+
+
+D.2.3. Streaminfoメタデータブロック +
+
+
+
+
+

+Most of the streaminfo metadata block, including its header, is the same as in example 1, so only parts that are different are listed in the following table. +

+
+
+

+ヘッダーを含むStreaminfoメタデータブロックのほとんどは、例1と同じであるため、次の表に異なる部分のみがリストされています。 +

+
+
+
+
+ 
+      +========+=========+============+=============================+
+      | Start  | Length  | Contents   | Description                 |
+      +========+=========+============+=============================+
+      | 0x04+0 | 1 bit   | 0b0        | Not the last metadata block |
+      +--------+---------+------------+-----------------------------+
+      | 0x08+0 | 2 bytes | 0x0010     | Min. block size 16          |
+      +--------+---------+------------+-----------------------------+
+      | 0x0a+0 | 2 bytes | 0x0010     | Max. block size 16          |
+      +--------+---------+------------+-----------------------------+
+      | 0x0c+0 | 3 bytes | 0x000017   | Min. frame size 23 bytes    |
+      +--------+---------+------------+-----------------------------+
+      | 0x0f+0 | 3 bytes | 0x000044   | Max. frame size 68 bytes    |
+      +--------+---------+------------+-----------------------------+
+      | 0x15+4 | 36 bits | 0b0000,    | Total no. of samples 19     |
+      |        |         | 0x00000013 |                             |
+      +--------+---------+------------+-----------------------------+
+      | 0x1a   | 16      | (...)      | MD5 checksum                |
+      |        | bytes   |            |                             |
+      +--------+---------+------------+-----------------------------+
+
+                                  Table 32
+
+
+
+
+
+

+This time, the minimum and maximum block sizes are reflected in the file: there is one block of 16 samples, and the last block (which has 3 samples) is not considered for the minimum block size. The MD5 checksum is 0xd5b0 5649 75e9 8b8d 8b93 0422 757b 8103. This will be verified at the end of this example. +

+
+
+

+今回は、最小および最大ブロックサイズがファイルに反映されます。16個のサンプルのブロックが1つあり、最後のブロック（3つのサンプルがある）は最小ブロックサイズでは考慮されません。MD5チェックサムは0xD5B0 5649 75E9 8B8D 8B93 0422 757B 8103です。これは、この例の最後に検証されます。 +

+
+
+
+
+
+D.2.4. Seek Table +
+
+
+
+D.2.4. テーブルを探します +
+
+
+
+
+

+The seek table metadata block only holds one entry. It is not really useful here, as it points to the first frame, but it is enough for this example. The seek table metadata block is broken down in the following table. +

+
+
+

+Seek Table Metadataブロックには、1つのエントリのみが保持されます。最初のフレームを指しているため、ここでは本当に役に立ちませんが、この例には十分です。シークテーブルメタデータブロックは、次の表で分解されます。 +

+
+
+
+
+ 
+            +========+========+====================+================+
+            | Start  | Length | Contents           | Description    |
+            +========+========+====================+================+
+            | 0x2a+0 | 1 bit  | 0b0                | Not the last   |
+            |        |        |                    | metadata block |
+            +--------+--------+--------------------+----------------+
+            | 0x2a+1 | 7 bits | 0b0000011          | Seek table     |
+            |        |        |                    | metadata block |
+            +--------+--------+--------------------+----------------+
+            | 0x2b+0 | 3      | 0x000012           | Length 18      |
+            |        | bytes  |                    | bytes          |
+            +--------+--------+--------------------+----------------+
+            | 0x2e+0 | 8      | 0x0000000000000000 | Seek point to  |
+            |        | bytes  |                    | sample 0       |
+            +--------+--------+--------------------+----------------+
+            | 0x36+0 | 8      | 0x0000000000000000 | Seek point to  |
+            |        | bytes  |                    | offset 0       |
+            +--------+--------+--------------------+----------------+
+            | 0x3e+0 | 2      | 0x0010             | Seek point to  |
+            |        | bytes  |                    | block size 16  |
+            +--------+--------+--------------------+----------------+
+
+                                     Table 33
+
+
+
+
+
+
+D.2.5. Vorbis Comment +
+
+
+
+D.2.5. Vorbisコメント +
+
+
+
+
+

+The Vorbis comment metadata block contains the vendor string and a single comment. It is broken down in the following table. +

+
+
+

+Vorbisコメントメタデータブロックには、ベンダー文字列と単一のコメントが含まれています。次の表に分解されます。 +

+
+
+
+
+ 
+  +========+==========+============+===============================+
+  | Start  | Length   | Contents   | Description                   |
+  +========+==========+============+===============================+
+  | 0x40+0 | 1 bit    | 0b0        | Not the last metadata block   |
+  +--------+----------+------------+-------------------------------+
+  | 0x40+1 | 7 bits   | 0b0000100  | Vorbis comment metadata block |
+  +--------+----------+------------+-------------------------------+
+  | 0x41+0 | 3 bytes  | 0x00003a   | Length 58 bytes               |
+  +--------+----------+------------+-------------------------------+
+  | 0x44+0 | 4 bytes  | 0x20000000 | Vendor string length 32 bytes |
+  +--------+----------+------------+-------------------------------+
+  | 0x48+0 | 32 bytes | (...)      | Vendor string                 |
+  +--------+----------+------------+-------------------------------+
+  | 0x68+0 | 4 bytes  | 0x01000000 | Number of fields 1            |
+  +--------+----------+------------+-------------------------------+
+  | 0x6c+0 | 4 bytes  | 0x0e000000 | Field length 14 bytes         |
+  +--------+----------+------------+-------------------------------+
+  | 0x70+0 | 14 bytes | (...)      | Field contents                |
+  +--------+----------+------------+-------------------------------+
+
+                               Table 34
+
+
+
+
+
+

+The vendor string is reference libFLAC 1.3.3 20190804, and the field contents of the only field is +

+
+
+

+ベンダー文字列はリファレンスlibflac 1.3.3 20190804であり、フィールドの唯一のフィールドの内容は +

+
+
+
+
+ 
+   TITLE=שלום
+
+
+
+
+
+

+where in direction of reading, the sequence of characters forming the field content is: "ש" (HEBREW LETTER SHIN, U+05E9), "ל" (HEBREW LETTER LAMED, U+05DC), "ו" (HEBREW LETTER VAV, U+05D5), "ם" (HEBREW LETTER FINAL MEM, U+05DD). +

+
+
+

+読み方の方向では、フィールドコンテンツを形成する文字のシーケンスは、「ש」（ヘブライ文字Shin、U+05e9）、「ל」（ヘブライ文字leall、u+05dc）、 "וו"（ヘブライ文字vav、u+05d5）、「ם」（ヘブライ文字最終mem、u+05dd）。 +

+
+
+
+
+

+The Vorbis comment field is 14 bytes but only 10 characters in size, because it contains four 2-byte characters. +

+
+
+

+Vorbisコメントフィールドは14バイトですが、4バイト文字が4つ含まれているため、サイズは10文字のみです。 +

+
+
+
+
+
+D.2.6. Padding +
+
+
+
+D.2.6. パディング +
+
+
+
+
+

+The last metadata block is a (very short) padding block. +

+
+
+

+最後のメタデータブロックは、（非常に短い）パディングブロックです。 +

+
+
+
+
+ 
+      +========+=========+================+========================+
+      | Start  | Length  | Contents       | Description            |
+      +========+=========+================+========================+
+      | 0x7e+0 | 1 bit   | 0b1            | Last metadata block    |
+      +--------+---------+----------------+------------------------+
+      | 0x7e+1 | 7 bits  | 0b0000001      | Padding metadata block |
+      +--------+---------+----------------+------------------------+
+      | 0x7f+0 | 3 bytes | 0x000006       | Length 6 byte          |
+      +--------+---------+----------------+------------------------+
+      | 0x82+0 | 6 bytes | 0x000000000000 | Padding bytes          |
+      +--------+---------+----------------+------------------------+
+
+                                 Table 35
+
+
+
+
+
+
+D.2.7. First Audio Frame +
+
+
+
+D.2.7. 最初のオーディオフレーム +
+
+
+
+
+

+The frame header starts at position 0x88 and is broken down in the following table. +

+
+
+

+フレームヘッダーは位置0x88から始まり、次の表で分解されます。 +

+
+
+
+
+ 
+          +========+=========+=================+===================+
+          | Start  | Length  | Contents        | Description       |
+          +========+=========+=================+===================+
+          | 0x88+0 | 15 bits | 0xff, 0b1111100 | Frame sync        |
+          +--------+---------+-----------------+-------------------+
+          | 0x89+7 | 1 bit   | 0b0             | Blocking strategy |
+          +--------+---------+-----------------+-------------------+
+          | 0x8a+0 | 4 bits  | 0b0110          | 8-bit block size  |
+          |        |         |                 | further down      |
+          +--------+---------+-----------------+-------------------+
+          | 0x8a+4 | 4 bits  | 0b1001          | Sample rate 44.1  |
+          |        |         |                 | kHz               |
+          +--------+---------+-----------------+-------------------+
+          | 0x8b+0 | 4 bits  | 0b1001          | Side-right stereo |
+          +--------+---------+-----------------+-------------------+
+          | 0x8b+4 | 3 bits  | 0b100           | Bit depth 16 bit  |
+          +--------+---------+-----------------+-------------------+
+          | 0x8b+7 | 1 bit   | 0b0             | Mandatory 0 bit   |
+          +--------+---------+-----------------+-------------------+
+          | 0x8c+0 | 1 byte  | 0x00            | Frame number 0    |
+          +--------+---------+-----------------+-------------------+
+          | 0x8d+0 | 1 byte  | 0x0f            | Block size 16     |
+          +--------+---------+-----------------+-------------------+
+          | 0x8e+0 | 1 byte  | 0x99            | Frame header CRC  |
+          +--------+---------+-----------------+-------------------+
+
+                                   Table 36
+
+
+
+
+
+

+The first subframe starts at byte 0x8f, and it is broken down in the following table, excluding the coded residual. As this subframe codes for a side channel, the bit depth is increased by 1 bit from 16 bits to 17 bits. This is most clearly present in the unencoded warm-up sample. +

+
+
+

+最初のサブフレームはBYTE 0x8Fで始まり、コード化された残差を除き、次の表で分解されます。このサブフレームがサイドチャネルをコードするため、ビットの深さは16ビットから17ビットから1ビットから1ビット増加します。これは、エンコードされていないウォームアップサンプルに最も明確に存在します。 +

+
+
+
+
+ 
+      +========+=========+=============+===========================+
+      | Start  | Length  | Contents    | Description               |
+      +========+=========+=============+===========================+
+      | 0x8f+0 | 1 bit   | 0b0         | Mandatory 0 bit           |
+      +--------+---------+-------------+---------------------------+
+      | 0x8f+1 | 6 bits  | 0b001001    | Fixed subframe, 1st order |
+      +--------+---------+-------------+---------------------------+
+      | 0x8f+7 | 1 bit   | 0b0         | No wasted bits used       |
+      +--------+---------+-------------+---------------------------+
+      | 0x90+0 | 17 bits | 0x0867, 0b0 | Unencoded warm-up sample  |
+      +--------+---------+-------------+---------------------------+
+
+                                 Table 37
+
+
+
+
+
+

+The coded residual is broken down in the following table. All quotients are unary coded, and all remainders are stored unencoded with a number of bits specified by the Rice parameter. +

+
+
+

+コード化された残差は、次の表に分解されます。すべての商は単位コード化されており、すべての残りは、イネパラメーターによって指定された多数のビットでエンコードされていない保存されます。 +

+
+
+
+
+ 
+              +========+========+=================+=================+
+              | Start  | Length | Contents        | Description     |
+              +========+========+=================+=================+
+              | 0x92+1 | 2 bits | 0b00            | Rice code with  |
+              |        |        |                 | 4-bit parameter |
+              +--------+--------+-----------------+-----------------+
+              | 0x92+3 | 4 bits | 0b0000          | Partition order |
+              |        |        |                 | 0               |
+              +--------+--------+-----------------+-----------------+
+              | 0x92+7 | 4 bits | 0b1011          | Rice parameter  |
+              |        |        |                 | 11              |
+              +--------+--------+-----------------+-----------------+
+              | 0x93+3 | 4 bits | 0b0001          | Quotient 3      |
+              +--------+--------+-----------------+-----------------+
+              | 0x93+7 | 11     | 0b00011110100   | Remainder 244   |
+              |        | bits   |                 |                 |
+              +--------+--------+-----------------+-----------------+
+              | 0x95+2 | 2 bits | 0b01            | Quotient 1      |
+              +--------+--------+-----------------+-----------------+
+              | 0x95+4 | 11     | 0b01000100001   | Remainder 545   |
+              |        | bits   |                 |                 |
+              +--------+--------+-----------------+-----------------+
+              | 0x96+7 | 2 bits | 0b01            | Quotient 1      |
+              +--------+--------+-----------------+-----------------+
+              | 0x97+1 | 11     | 0b00110011000   | Remainder 408   |
+              |        | bits   |                 |                 |
+              +--------+--------+-----------------+-----------------+
+              | 0x98+4 | 1 bit  | 0b1             | Quotient 0      |
+              +--------+--------+-----------------+-----------------+
+              | 0x98+5 | 11     | 0b11101011101   | Remainder 1885  |
+              |        | bits   |                 |                 |
+              +--------+--------+-----------------+-----------------+
+              | 0x9a+0 | 1 bit  | 0b1             | Quotient 0      |
+              +--------+--------+-----------------+-----------------+
+              | 0x9a+1 | 11     | 0b11101110000   | Remainder 1904  |
+              |        | bits   |                 |                 |
+              +--------+--------+-----------------+-----------------+
+              | 0x9b+4 | 1 bit  | 0b1             | Quotient 0      |
+              +--------+--------+-----------------+-----------------+
+              | 0x9b+5 | 11     | 0b10101101111   | Remainder 1391  |
+              |        | bits   |                 |                 |
+              +--------+--------+-----------------+-----------------+
+              | 0x9d+0 | 1 bit  | 0b1             | Quotient 0      |
+              +--------+--------+-----------------+-----------------+
+              | 0x9d+1 | 11     | 0b11000000000   | Remainder 1536  |
+              |        | bits   |                 |                 |
+              +--------+--------+-----------------+-----------------+
+              | 0x9e+4 | 1 bit  | 0b1             | Quotient 0      |
+              +--------+--------+-----------------+-----------------+
+              | 0x9e+5 | 11     | 0b10000010111   | Remainder 1047  |
+              |        | bits   |                 |                 |
+              +--------+--------+-----------------+-----------------+
+              | 0xa0+0 | 1 bit  | 0b1             | Quotient 0      |
+              +--------+--------+-----------------+-----------------+
+              | 0xa0+1 | 11     | 0b10010101110   | Remainder 1198  |
+              |        | bits   |                 |                 |
+              +--------+--------+-----------------+-----------------+
+              | 0xa1+4 | 1 bit  | 0b1             | Quotient 0      |
+              +--------+--------+-----------------+-----------------+
+              | 0xa1+5 | 11     | 0b01100100001   | Remainder 801   |
+              |        | bits   |                 |                 |
+              +--------+--------+-----------------+-----------------+
+              | 0xa3+0 | 13     | 0b0000000000001 | Quotient 12     |
+              |        | bits   |                 |                 |
+              +--------+--------+-----------------+-----------------+
+              | 0xa4+5 | 11     | 0b11011100111   | Remainder 1767  |
+              |        | bits   |                 |                 |
+              +--------+--------+-----------------+-----------------+
+              | 0xa6+0 | 1 bit  | 0b1             | Quotient 0      |
+              +--------+--------+-----------------+-----------------+
+              | 0xa6+1 | 11     | 0b01001110111   | Remainder 631   |
+              |        | bits   |                 |                 |
+              +--------+--------+-----------------+-----------------+
+              | 0xa7+4 | 1 bit  | 0b1             | Quotient 0      |
+              +--------+--------+-----------------+-----------------+
+              | 0xa7+5 | 11     | 0b01000100100   | Remainder 548   |
+              |        | bits   |                 |                 |
+              +--------+--------+-----------------+-----------------+
+              | 0xa9+0 | 1 bit  | 0b1             | Quotient 0      |
+              +--------+--------+-----------------+-----------------+
+              | 0xa9+1 | 11     | 0b01000010101   | Remainder 533   |
+              |        | bits   |                 |                 |
+              +--------+--------+-----------------+-----------------+
+              | 0xaa+4 | 1 bit  | 0b1             | Quotient 0      |
+              +--------+--------+-----------------+-----------------+
+              | 0xaa+5 | 11     | 0b00100001100   | Remainder 268   |
+              |        | bits   |                 |                 |
+              +--------+--------+-----------------+-----------------+
+
+                                      Table 38
+
+
+
+
+
+

+At this point, the decoder should know it is done decoding the coded residual, as it received 16 samples: 1 warm-up sample and 15 residual samples. Each residual sample can be calculated from the quotient and remainder and from undoing the zigzag encoding. For example, the value of the first zigzag-encoded residual sample is 3 * 2^11 + 244 = 6388. As this is an even number, the zigzag encoding is undone by dividing by 2; the residual sample value is 3194. This is done for all residual samples in the next table. +

+
+
+

+この時点で、デコーダーは16のサンプルを受け取ったため、コード化された残差を解読していることを知っている必要があります：1つのウォームアップサンプルと15の残留サンプル。各残差サンプルは、商と残りから、Zigzagエンコーディングを元に戻すことから計算できます。たとえば、最初のジグザグエンコード残差サンプルの値は3 * 2^11 + 244 = 6388です。これは偶数であるため、ジグザグエンコーディングは2で除算することで元に戻されます。残差サンプル値は3194です。これは、次の表のすべての残差サンプルに対して行われます。 +

+
+
+
+
+ 
+    +==========+===========+================+=======================+
+    | Quotient | Remainder | Zigzag Encoded | Residual Sample Value |
+    +==========+===========+================+=======================+
+    | 3        | 244       | 6388           | 3194                  |
+    +----------+-----------+----------------+-----------------------+
+    | 1        | 545       | 2593           | -1297                 |
+    +----------+-----------+----------------+-----------------------+
+    | 1        | 408       | 2456           | 1228                  |
+    +----------+-----------+----------------+-----------------------+
+    | 0        | 1885      | 1885           | -943                  |
+    +----------+-----------+----------------+-----------------------+
+    | 0        | 1904      | 1904           | 952                   |
+    +----------+-----------+----------------+-----------------------+
+    | 0        | 1391      | 1391           | -696                  |
+    +----------+-----------+----------------+-----------------------+
+    | 0        | 1536      | 1536           | 768                   |
+    +----------+-----------+----------------+-----------------------+
+    | 0        | 1047      | 1047           | -524                  |
+    +----------+-----------+----------------+-----------------------+
+    | 0        | 1198      | 1198           | 599                   |
+    +----------+-----------+----------------+-----------------------+
+    | 0        | 801       | 801            | -401                  |
+    +----------+-----------+----------------+-----------------------+
+    | 12       | 1767      | 26343          | -13172                |
+    +----------+-----------+----------------+-----------------------+
+    | 0        | 631       | 631            | -316                  |
+    +----------+-----------+----------------+-----------------------+
+    | 0        | 548       | 548            | 274                   |
+    +----------+-----------+----------------+-----------------------+
+    | 0        | 533       | 533            | -267                  |
+    +----------+-----------+----------------+-----------------------+
+    | 0        | 268       | 268            | 134                   |
+    +----------+-----------+----------------+-----------------------+
+
+                                 Table 39
+
+
+
+
+
+

+In this case, using a Rice code is more efficient than storing values unencoded. The Rice code (excluding the partition order and parameter) is 199 bits in length. The largest residual value (-13172) would need 15 bits to be stored unencoded, so storing all 15 samples with 15 bits results in a sequence with a length of 225 bits. +

+
+
+

+この場合、稲法を使用することは、エンコードされていない値を保存するよりも効率的です。稲法（パーティションの順序とパラメーターを除く）の長さは199ビットです。最大の残留値（-13172）は、エンコードなしで15ビットを保存する必要があるため、15ビットの15サンプルすべてを保存すると、長さ225ビットのシーケンスになります。 +

+
+
+
+
+

+The next step is using the predictor and the residuals to restore the sample values. As this subframe uses a fixed predictor with order 1, the residual value is added to the value of the previous sample. +

+
+
+

+次のステップは、予測子と残差を使用してサンプル値を復元することです。このサブフレームは、順序1で固定予測子を使用するため、残差は前のサンプルの値に追加されます。 +

+
+
+
+
+ 
+                                        +===========+==============+
+                                        | Residual  | Sample Value |
+                                        +===========+==============+
+                                        | (warm-up) | 4302         |
+                                        +-----------+--------------+
+                                        | 3194      | 7496         |
+                                        +-----------+--------------+
+                                        | -1297     | 6199         |
+                                        +-----------+--------------+
+                                        | 1228      | 7427         |
+                                        +-----------+--------------+
+                                        | -943      | 6484         |
+                                        +-----------+--------------+
+                                        | 952       | 7436         |
+                                        +-----------+--------------+
+                                        | -696      | 6740         |
+                                        +-----------+--------------+
+                                        | 768       | 7508         |
+                                        +-----------+--------------+
+                                        | -524      | 6984         |
+                                        +-----------+--------------+
+                                        | 599       | 7583         |
+                                        +-----------+--------------+
+                                        | -401      | 7182         |
+                                        +-----------+--------------+
+                                        | -13172    | -5990        |
+                                        +-----------+--------------+
+                                        | -316      | -6306        |
+                                        +-----------+--------------+
+                                        | 274       | -6032        |
+                                        +-----------+--------------+
+                                        | -267      | -6299        |
+                                        +-----------+--------------+
+                                        | 134       | -6165        |
+                                        +-----------+--------------+
+
+                                                  Table 40
+
+
+
+
+
+

+With this, the decoding of the first subframe is complete. The decoding of the second subframe is very similar, as it also uses a fixed predictor of order 1. This is left as an exercise for the reader; the results are in the next table. The next step is undoing stereo decorrelation, which is done in the following table. As the stereo decorrelation is side-right, the samples in the right channel come directly from the second subframe, while the samples in the left channel are found by adding the values of both subframes for each sample. +

+
+
+

+これにより、最初のサブフレームのデコードが完了します。2番目のサブフレームのデコードは、注文1の固定予測因子も使用するため、非常に似ています。これは、読者の演習として残されています。結果は次の表にあります。次のステップは、次の表で行われるステレオ分離を元に戻すことです。ステレオの分離はサイドロイトであるため、右チャネルのサンプルは2番目のサブフレームから直接送られますが、左チャネルのサンプルは、各サンプルの両方のサブフレームの値を追加することで見つかります。 +

+
+
+
+
+ 
+                        +============+============+========+=======+
+                        | Subframe 1 | Subframe 2 | Left   | Right |
+                        +============+============+========+=======+
+                        | 4302       | 6070       | 10372  | 6070  |
+                        +------------+------------+--------+-------+
+                        | 7496       | 10545      | 18041  | 10545 |
+                        +------------+------------+--------+-------+
+                        | 6199       | 8743       | 14942  | 8743  |
+                        +------------+------------+--------+-------+
+                        | 7427       | 10449      | 17876  | 10449 |
+                        +------------+------------+--------+-------+
+                        | 6484       | 9143       | 15627  | 9143  |
+                        +------------+------------+--------+-------+
+                        | 7436       | 10463      | 17899  | 10463 |
+                        +------------+------------+--------+-------+
+                        | 6740       | 9502       | 16242  | 9502  |
+                        +------------+------------+--------+-------+
+                        | 7508       | 10569      | 18077  | 10569 |
+                        +------------+------------+--------+-------+
+                        | 6984       | 9840       | 16824  | 9840  |
+                        +------------+------------+--------+-------+
+                        | 7583       | 10680      | 18263  | 10680 |
+                        +------------+------------+--------+-------+
+                        | 7182       | 10113      | 17295  | 10113 |
+                        +------------+------------+--------+-------+
+                        | -5990      | -8428      | -14418 | -8428 |
+                        +------------+------------+--------+-------+
+                        | -6306      | -8895      | -15201 | -8895 |
+                        +------------+------------+--------+-------+
+                        | -6032      | -8476      | -14508 | -8476 |
+                        +------------+------------+--------+-------+
+                        | -6299      | -8896      | -15195 | -8896 |
+                        +------------+------------+--------+-------+
+                        | -6165      | -8653      | -14818 | -8653 |
+                        +------------+------------+--------+-------+
+
+                                          Table 41
+
+
+
+
+
+

+As the second subframe ends byte-aligned, no padding bits follow it. Finally, the last 2 bytes of the frame contain the frame CRC. +

+
+
+

+2番目のサブフレームがバイトアラインを終了すると、パディングビットはそれに続いていません。最後に、フレームの最後の2バイトにはフレームCRCが含まれています。 +

+
+
+
+
+
+D.2.8. Second Audio Frame +
+
+
+
+D.2.8. 2番目のオーディオフレーム +
+
+
+
+
+

+The second audio frame is very similar to the frame decoded in the first example, but this time, 3 samples (not 1) are present. +

+
+
+

+2番目のオーディオフレームは、最初の例でデコードされたフレームに非常に似ていますが、今回は3つのサンプル（1ではない）が存在します。 +

+
+
+
+
+

+The frame header starts at position 0xcc and is broken down in the following table. +

+
+
+

+フレームヘッダーは位置0xccで始まり、次の表で分解されます。 +

+
+
+
+
+ 
+          +========+=========+=================+===================+
+          | Start  | Length  | Contents        | Description       |
+          +========+=========+=================+===================+
+          | 0xcc+0 | 15 bits | 0xff, 0b1111100 | Frame sync        |
+          +--------+---------+-----------------+-------------------+
+          | 0xcd+7 | 1 bit   | 0b0             | Blocking strategy |
+          +--------+---------+-----------------+-------------------+
+          | 0xce+0 | 4 bits  | 0b0110          | 8-bit block size  |
+          |        |         |                 | further down      |
+          +--------+---------+-----------------+-------------------+
+          | 0xce+4 | 4 bits  | 0b1001          | Sample rate 44.1  |
+          |        |         |                 | kHz               |
+          +--------+---------+-----------------+-------------------+
+          | 0xcf+0 | 4 bits  | 0b0001          | Stereo, no        |
+          |        |         |                 | decorrelation     |
+          +--------+---------+-----------------+-------------------+
+          | 0xcf+4 | 3 bits  | 0b100           | Bit depth 16 bits |
+          +--------+---------+-----------------+-------------------+
+          | 0xcf+7 | 1 bit   | 0b0             | Mandatory 0 bit   |
+          +--------+---------+-----------------+-------------------+
+          | 0xd0+0 | 1 byte  | 0x01            | Frame number 1    |
+          +--------+---------+-----------------+-------------------+
+          | 0xd1+0 | 1 byte  | 0x02            | Block size 3      |
+          +--------+---------+-----------------+-------------------+
+          | 0xd2+0 | 1 byte  | 0xa4            | Frame header CRC  |
+          +--------+---------+-----------------+-------------------+
+
+                                   Table 42
+
+
+
+
+
+

+The first subframe starts at 0xd3+0 and is broken down in the following table. +

+
+
+

+最初のサブフレームは0xD3+0から始まり、次の表で分解されます。 +

+
+
+
+
+ 
+            +========+=========+==========+=========================+
+            | Start  | Length  | Contents | Description             |
+            +========+=========+==========+=========================+
+            | 0xd3+0 | 1 bit   | 0b0      | Mandatory 0 bit         |
+            +--------+---------+----------+-------------------------+
+            | 0xd3+1 | 6 bits  | 0b000001 | Verbatim subframe       |
+            +--------+---------+----------+-------------------------+
+            | 0xd3+7 | 1 bit   | 0b0      | No wasted bits used     |
+            +--------+---------+----------+-------------------------+
+            | 0xd4+0 | 16 bits | 0xc382   | 16-bit unencoded sample |
+            +--------+---------+----------+-------------------------+
+            | 0xd6+0 | 16 bits | 0xc40b   | 16-bit unencoded sample |
+            +--------+---------+----------+-------------------------+
+            | 0xd8+0 | 16 bits | 0xc14a   | 16-bit unencoded sample |
+            +--------+---------+----------+-------------------------+
+
+                                     Table 43
+
+
+
+
+
+

+The second subframe starts at 0xda+0 and is broken down in the following table. +

+
+
+

+2番目のサブフレームは0xDa+0から始まり、次の表で分解されます。 +

+
+
+
+
+ 
+  +========+=========+===================+=========================+
+  | Start  | Length  | Contents          | Description             |
+  +========+=========+===================+=========================+
+  | 0xda+0 | 1 bit   | 0b0               | Mandatory 0 bit         |
+  +--------+---------+-------------------+-------------------------+
+  | 0xda+1 | 6 bits  | 0b000001          | Verbatim subframe       |
+  +--------+---------+-------------------+-------------------------+
+  | 0xda+7 | 1 bit   | 0b1               | Wasted bits used        |
+  +--------+---------+-------------------+-------------------------+
+  | 0xdb+0 | 1 bit   | 0b1               | 1 wasted bit used       |
+  +--------+---------+-------------------+-------------------------+
+  | 0xdb+1 | 15 bits | 0b110111001001000 | 15-bit unencoded sample |
+  +--------+---------+-------------------+-------------------------+
+  | 0xdd+0 | 15 bits | 0b110111010000001 | 15-bit unencoded sample |
+  +--------+---------+-------------------+-------------------------+
+  | 0xde+7 | 15 bits | 0b110110110011111 | 15-bit unencoded sample |
+  +--------+---------+-------------------+-------------------------+
+
+                               Table 44
+
+
+
+
+
+

+As this subframe uses wasted bits, the 15-bit unencoded samples need to be shifted left by 1 bit. For example, sample 1 is stored as -4536 and becomes -9072 after shifting left 1 bit. +

+
+
+

+このサブフレームは無駄なビットを使用するため、15ビットの非エンエンコードサンプルを1ビットでシフトする必要があります。たとえば、サンプル1は-4536として保存され、左1ビットをシフトした後に-9072になります。 +

+
+
+
+
+

+As the last subframe does not end on byte alignment, 2 padding bits are added before the 2-byte frame CRC, which follows at 0xe1+0. +

+
+
+

+最後のサブフレームはバイトアラインメントで終了しないため、2バイトフレームCRCの前に2つのパディングビットが追加されます。これは0xe1+0です。 +

+
+
+
+
+
+D.2.9. MD5 Checksum Verification +
+
+
+
+D.2.9. MD5チェックサム検証 +
+
+
+
+
+

+All samples in the file have been decoded, and we can now verify the MD5 checksum. All sample values must be interleaved and stored signed coded little-endian. The result of this follows in groups of 12 samples (i.e., 6 interchannel samples) per line. +

+
+
+

+ファイル内のすべてのサンプルがデコードされており、MD5チェックサムを確認できるようになりました。すべてのサンプル値はインターリーブし、署名されたコード付きリトルエンディアンを保存する必要があります。これの結果は、1行あたり12のサンプル（つまり、6つのインターチャネルサンプル）のグループになります。 +

+
+
+
+
+ 
+   0x8428 B617 7946 3129 5E3A 2722 D445 D128 0B3D B723 EB45 DF28
+   0x723f 1E25 9D46 4929 B841 7026 5747 B829 8F43 8127 AEC7 14DF
+   0x9FC4 41DD 54C7 E4DE A5C4 40DD 1EC6 33DE 82C3 90DC 0BC4 02DD
+   0x4AC1 3EDB
+
+
+
+
+
+

+The MD5 checksum of this is indeed the same as the one found in the streaminfo metadata block. +

+
+
+

+これのMD5チェックサムは、確かにStreaminfoメタデータブロックに見られるものと同じです。 +

+
+
+
+
+
+D.3. Decoding Example 3 +
+
+
+
+D.3. デコード例3 +
+
+
+
+
+

+This example is once again a very short FLAC file. The focus of this example is on decoding a subframe with a linear predictor and a coded residual with more than one partition. +

+
+
+

+この例は、再び非常に短いFLACファイルです。この例の焦点は、線形予測因子と複数のパーティションを備えたコード化された残差を備えたサブフレームをデコードすることです。 +

+
+
+
+
+
+D.3.1. Example File 3 in Hexadecimal Representation +
+
+
+
+D.3.1. 16進表現の例ファイル3 +
+
+
+
+
+ 
+   00000000: 664c 6143 8000 0022 1000 1000  fLaC..."....
+   0000000c: 0000 1f00 001f 07d0 0070 0000  .........p..
+   00000018: 0018 f8f9 e396 f5cb cfc6 dc80  ............
+   00000024: 7f99 7790 6b32 fff8 6802 0017  ..w.k2..h...
+   00000030: e944 004f 6f31 3d10 47d2 27cb  .D.Oo1=.G.'.
+   0000003c: 6d09 0831 452b dc28 2222 8057  m..1E+.("".W
+   00000048: a3                             .
+
+
+
+
+
+
+D.3.2. Example File 3 in Binary Representation (Only Audio Frame) +
+
+
+
+D.3.2. バイナリ表現の例ファイル3（オーディオフレームのみ） +
+
+
+
+
+ 
+   0000002a: 11111111 11111000 01101000 00000010  ..h.
+   0000002e: 00000000 00010111 11101001 01000100  ...D
+   00000032: 00000000 01001111 01101111 00110001  .Oo1
+   00000036: 00111101 00010000 01000111 11010010  =.G.
+   0000003a: 00100111 11001011 01101101 00001001  '.m.
+   0000003e: 00001000 00110001 01000101 00101011  .1E+
+   00000042: 11011100 00101000 00100010 00100010  .(""
+   00000046: 10000000 01010111 10100011           .W.
+
+
+
+
+
+
+D.3.3. Streaminfo Metadata Block +
+
+
+
+D.3.3. Streaminfoメタデータブロック +
+
+
+
+
+

+Most of the streaminfo metadata block, including its header, is the same as in example 1, so only parts that are different are listed in the following table. +

+
+
+

+ヘッダーを含むStreaminfoメタデータブロックのほとんどは、例1と同じであるため、次の表に異なる部分のみがリストされています。 +

+
+
+
+
+ 
++========+==========+====================+==========================+
+| Start  | Length   | Contents           | Description              |
++========+==========+====================+==========================+
+| 0x0c+0 | 3 bytes  | 0x00001f           | Min. frame size 31 bytes |
++--------+----------+--------------------+--------------------------+
+| 0x0f+0 | 3 bytes  | 0x00001f           | Max. frame size 31 bytes |
++--------+----------+--------------------+--------------------------+
+| 0x12+0 | 20 bits  | 0x07d0, 0x0000     | Sample rate 32000 hertz  |
++--------+----------+--------------------+--------------------------+
+| 0x14+4 | 3 bits   | 0b000              | 1 channel                |
++--------+----------+--------------------+--------------------------+
+| 0x14+7 | 5 bits   | 0b00111            | Sample bit depth 8 bits  |
++--------+----------+--------------------+--------------------------+
+| 0x15+4 | 36 bits  | 0b0000, 0x00000018 | Total no. of samples 24  |
++--------+----------+--------------------+--------------------------+
+| 0x1a   | 16       | (...)              | MD5 checksum             |
+|        | bytes    |                    |                          |
++--------+----------+--------------------+--------------------------+
+
+                               Table 45
+
+
+
+
+
+
+D.3.4. Audio Frame +
+
+
+
+D.3.4. オーディオフレーム +
+
+
+
+
+

+The frame header starts at position 0x2a and is broken down in the following table. +

+
+
+

+フレームヘッダーは位置0x2aから始まり、次の表で分解されます。 +

+
+
+
+
+ 
+          +========+=========+=================+===================+
+          | Start  | Length  | Contents        | Description       |
+          +========+=========+=================+===================+
+          | 0x2a+0 | 15 bits | 0xff, 0b1111100 | Frame sync        |
+          +--------+---------+-----------------+-------------------+
+          | 0x2b+7 | 1 bit   | 0b0             | blocking strategy |
+          +--------+---------+-----------------+-------------------+
+          | 0x2c+0 | 4 bits  | 0b0110          | 8-bit block size  |
+          |        |         |                 | further down      |
+          +--------+---------+-----------------+-------------------+
+          | 0x2c+4 | 4 bits  | 0b1000          | Sample rate 32    |
+          |        |         |                 | kHz               |
+          +--------+---------+-----------------+-------------------+
+          | 0x2d+0 | 4 bits  | 0b0000          | Mono audio (1     |
+          |        |         |                 | channel)          |
+          +--------+---------+-----------------+-------------------+
+          | 0x2d+4 | 3 bits  | 0b001           | Bit depth 8 bits  |
+          +--------+---------+-----------------+-------------------+
+          | 0x2d+7 | 1 bit   | 0b0             | Mandatory 0 bit   |
+          +--------+---------+-----------------+-------------------+
+          | 0x2e+0 | 1 byte  | 0x00            | Frame number 0    |
+          +--------+---------+-----------------+-------------------+
+          | 0x2f+0 | 1 byte  | 0x17            | Block size 24     |
+          +--------+---------+-----------------+-------------------+
+          | 0x30+0 | 1 byte  | 0xe9            | Frame header CRC  |
+          +--------+---------+-----------------+-------------------+
+
+                                   Table 46
+
+
+
+
+
+

+The first and only subframe starts at byte 0x31. It is broken down in the following table, without the coded residual. +

+
+
+

+最初の唯一のサブフレームは、BYTE 0x31で始まります。コード化された残差なしで、次の表に分解されます。 +

+
+
+
+
+ 
+                +========+========+==========+=====================+
+                | Start  | Length | Contents | Description         |
+                +========+========+==========+=====================+
+                | 0x31+0 | 1 bit  | 0b0      | Mandatory 0 bit     |
+                +--------+--------+----------+---------------------+
+                | 0x31+1 | 6 bits | 0b100010 | Linear prediction   |
+                |        |        |          | subframe, 3rd order |
+                +--------+--------+----------+---------------------+
+                | 0x31+7 | 1 bit  | 0b0      | No wasted bits used |
+                +--------+--------+----------+---------------------+
+                | 0x32+0 | 8 bits | 0x00     | Unencoded warm-up   |
+                |        |        |          | sample 0            |
+                +--------+--------+----------+---------------------+
+                | 0x33+0 | 8 bits | 0x4f     | Unencoded warm-up   |
+                |        |        |          | sample 79           |
+                +--------+--------+----------+---------------------+
+                | 0x34+0 | 8 bits | 0x6f     | Unencoded warm-up   |
+                |        |        |          | sample 111          |
+                +--------+--------+----------+---------------------+
+                | 0x35+0 | 4 bits | 0b0011   | Coefficient         |
+                |        |        |          | precision 4 bit     |
+                +--------+--------+----------+---------------------+
+                | 0x35+4 | 5 bits | 0b00010  | Prediction right    |
+                |        |        |          | shift 2             |
+                +--------+--------+----------+---------------------+
+                | 0x36+1 | 4 bits | 0b0111   | Predictor           |
+                |        |        |          | coefficient 7       |
+                +--------+--------+----------+---------------------+
+                | 0x36+5 | 4 bits | 0b1010   | Predictor           |
+                |        |        |          | coefficient -6      |
+                +--------+--------+----------+---------------------+
+                | 0x37+1 | 4 bits | 0b0010   | Predictor           |
+                |        |        |          | coefficient 2       |
+                +--------+--------+----------+---------------------+
+
+                                      Table 47
+
+
+
+
+
+

+The data stream continues with the coded residual, which is broken down in the following table. Residual partitions 3 and 4 are left as an exercise for the reader. +

+
+
+

+データストリームは、次の表に分解されているコード化された残差で続きます。残留パーティション3と4は、読者のための演習として残されています。 +

+
+
+
+
+ 
++========+========+==========+======================================+
+| Start  | Length | Contents | Description                          |
++========+========+==========+======================================+
+| 0x37+5 | 2 bits | 0b00     | Rice-coded residual,                 |
+|        |        |          | 4-bit parameter                      |
++--------+--------+----------+--------------------------------------+
+| 0x37+7 | 4 bits | 0b0010   | Partition order 2                    |
++--------+--------+----------+--------------------------------------+
+| 0x38+3 | 4 bits | 0b0011   | Rice parameter 3                     |
++--------+--------+----------+--------------------------------------+
+| 0x38+7 | 1 bit  | 0b1      | Quotient 0                           |
++--------+--------+----------+--------------------------------------+
+| 0x39+0 | 3 bits | 0b110    | Remainder 6                          |
++--------+--------+----------+--------------------------------------+
+| 0x39+3 | 1 bit  | 0b1      | Quotient 0                           |
++--------+--------+----------+--------------------------------------+
+| 0x39+4 | 3 bits | 0b001    | Remainder 1                          |
++--------+--------+----------+--------------------------------------+
+| 0x39+7 | 4 bits | 0b0001   | Quotient 3                           |
++--------+--------+----------+--------------------------------------+
+| 0x3a+3 | 3 bits | 0b001    | Remainder 1                          |
++--------+--------+----------+--------------------------------------+
+| 0x3a+6 | 4 bits | 0b1111   | No Rice parameter,                   |
+|        |        |          | escape code                          |
++--------+--------+----------+--------------------------------------+
+| 0x3b+2 | 5 bits | 0b00101  | Partition encoded                    |
+|        |        |          | with 5 bits                          |
++--------+--------+----------+--------------------------------------+
+| 0x3b+7 | 5 bits | 0b10110  | Residual -10                         |
++--------+--------+----------+--------------------------------------+
+| 0x3c+4 | 5 bits | 0b11010  | Residual -6                          |
++--------+--------+----------+--------------------------------------+
+| 0x3d+1 | 5 bits | 0b00010  | Residual 2                           |
++--------+--------+----------+--------------------------------------+
+| 0x3d+6 | 5 bits | 0b01000  | Residual 8                           |
++--------+--------+----------+--------------------------------------+
+| 0x3e+3 | 5 bits | 0b01000  | Residual 8                           |
++--------+--------+----------+--------------------------------------+
+| 0x3f+0 | 5 bits | 0b00110  | Residual 6                           |
++--------+--------+----------+--------------------------------------+
+| 0x3f+5 | 4 bits | 0b0010   | Rice parameter 2                     |
++--------+--------+----------+--------------------------------------+
+| 0x40+1 | 22     | (...)    | Residual partition 3                 |
+|        | bits   |          |                                      |
++--------+--------+----------+--------------------------------------+
+| 0x42+7 | 4 bits | 0b0001   | Rice parameter 1                     |
++--------+--------+----------+--------------------------------------+
+| 0x43+3 | 23     | (...)    | Residual partition 4                 |
+|        | bits   |          |                                      |
++--------+--------+----------+--------------------------------------+
+
+                               Table 48
+
+
+
+
+
+

+The frame ends with 6 padding bits and a 2-byte frame CRC. +

+
+
+

+フレームは、6つのパディングビットと2バイトのフレームCRCで終わります。 +

+
+
+
+
+

+To decode this subframe, 21 predictions have to be calculated and added to their corresponding residuals. This is a sequential process: as each prediction uses previous samples, it is not possible to start this decoding halfway through a subframe or decode a subframe with parallel threads. +

+
+
+

+このサブフレームをデコードするには、21の予測を計算し、対応する残差に追加する必要があります。これはシーケンシャルプロセスです。各予測は以前のサンプルを使用するため、サブフレームの途中でこのデコードを開始したり、並列スレッドでサブフレームをデコードすることはできません。 +

+
+
+
+
+

+The following table breaks down the calculation for each sample. For example, the predictor without shift value of row 4 is found by applying the predictor with the three warm-up samples: 7*111 - 6*79 + 2*0 = 303. This value is then shifted right by 2 bits: 303 >> 2 = 75. Then, the decoded residual sample is added: 75 + 3 = 78. +

+
+
+

+次の表は、各サンプルの計算を分解します。たとえば、行4のシフト値のない予測因子は、3つのウォームアップサンプルで予測子を適用することにより見つかります：7*111-6*79 + 2*0 = 303。この値は2ビットの右にシフトされます：303>> 2 =75。その後、デコードされた残留サンプルが追加されます：75 + 3 = 78。 +

+
+
+
+
+ 
+      +===========+=====================+===========+==============+
+      | Residual  | Predictor w/o Shift | Predictor | Sample Value |
+      +===========+=====================+===========+==============+
+      | (warm-up) | N/A                 | N/A       | 0            |
+      +-----------+---------------------+-----------+--------------+
+      | (warm-up) | N/A                 | N/A       | 79           |
+      +-----------+---------------------+-----------+--------------+
+      | (warm-up) | N/A                 | N/A       | 111          |
+      +-----------+---------------------+-----------+--------------+
+      | 3         | 303                 | 75        | 78           |
+      +-----------+---------------------+-----------+--------------+
+      | -1        | 38                  | 9         | 8            |
+      +-----------+---------------------+-----------+--------------+
+      | -13       | -190                | -48       | -61          |
+      +-----------+---------------------+-----------+--------------+
+      | -10       | -319                | -80       | -90          |
+      +-----------+---------------------+-----------+--------------+
+      | -6        | -248                | -62       | -68          |
+      +-----------+---------------------+-----------+--------------+
+      | 2         | -58                 | -15       | -13          |
+      +-----------+---------------------+-----------+--------------+
+      | 8         | 137                 | 34        | 42           |
+      +-----------+---------------------+-----------+--------------+
+      | 8         | 236                 | 59        | 67           |
+      +-----------+---------------------+-----------+--------------+
+      | 6         | 191                 | 47        | 53           |
+      +-----------+---------------------+-----------+--------------+
+      | 0         | 53                  | 13        | 13           |
+      +-----------+---------------------+-----------+--------------+
+      | -3        | -93                 | -24       | -27          |
+      +-----------+---------------------+-----------+--------------+
+      | -5        | -161                | -41       | -46          |
+      +-----------+---------------------+-----------+--------------+
+      | -4        | -134                | -34       | -38          |
+      +-----------+---------------------+-----------+--------------+
+      | -1        | -44                 | -11       | -12          |
+      +-----------+---------------------+-----------+--------------+
+      | 1         | 52                  | 13        | 14           |
+      +-----------+---------------------+-----------+--------------+
+      | 1         | 94                  | 23        | 24           |
+      +-----------+---------------------+-----------+--------------+
+      | 4         | 60                  | 15        | 19           |
+      +-----------+---------------------+-----------+--------------+
+      | 2         | 17                  | 4         | 6            |
+      +-----------+---------------------+-----------+--------------+
+      | 2         | -24                 | -6        | -4           |
+      +-----------+---------------------+-----------+--------------+
+      | 2         | -26                 | -7        | -5           |
+      +-----------+---------------------+-----------+--------------+
+      | 0         | 1                   | 0         | 0            |
+      +-----------+---------------------+-----------+--------------+
+
+                                 Table 49
+
+
+
+
+
+

+By lining up all these samples, we get the following input for the MD5 checksum calculation process: +

+
+
+

+これらすべてのサンプルを並べることにより、MD5チェックサム計算プロセスの次の入力が得られます。 +

+
+
+
+
+ 
+   0x004F 6F4E 08C3 A6BC F32A 4335 0DE5 D2DA F40E 1813 06FC FB00
+
+
+
+
+
+

+This indeed results in the MD5 checksum found in the streaminfo metadata block. +

+
+
+

+実際、これにより、StreaminfoメタデータブロックにあるMD5チェックサムが発生します。 +

+
+
+
+
+
+Acknowledgments +
+
+
+
+謝辞 +
+
+
+
+
+

+FLAC owes much to the many people who have advanced the audio compression field so freely. For instance: +

+
+
+

+FLACは、オーディオ圧縮フィールドを自由に進めた多くの人々に大いに負っています。例えば： +

+
+
+
+
+

+* Tony Robinson: He worked on Shorten, and his paper (see [Robinson-TR156]) is a good starting point on some of the basic methods used by FLAC. FLAC trivially extends and improves the fixed predictors, LPC coefficient quantization, and Rice coding used in Shorten. +

+
+
+

+* トニー・ロビンソン：彼はショーテンに取り組み、彼の論文（[ロビンソン-TR156を参照]を参照）は、FLACが使用する基本的な方法のいくつかの良い出発点です。FLACは、固定された予測因子、LPC係数量子化、および短縮で使用されるイネコーディングを簡単に拡張および改善します。 +

+
+
+
+
+

+* Solomon W. Golomb and Robert F. Rice: Their universal codes are used by FLAC's entropy coder. See [Rice]. +

+
+
+

+* Solomon W. GolombとRobert F. Rice：それらのユニバーサルコードは、FLACのエントロピーコーダーによって使用されています。[米]を参照してください。 +

+
+
+
+
+

+* Norman Levinson and James Durbin: The FLAC reference encoder uses an algorithm developed and refined by them for determining the LPC coefficients from the autocorrelation coefficients. See [Durbin]). +

+
+
+

+* Norman LevinsonとJames Durbin：FLACリファレンスエンコーダーは、自己相関係数からLPC係数を決定するために開発および改良されたアルゴリズムを使用します。[Durbin]を参照してください。 +

+
+
+
+
+

+* Claude Shannon: See [Shannon]. +

+
+
+

+* クロード・シャノン：[シャノン]を参照。 +

+
+
+
+
+

+The FLAC format, the FLAC reference implementation [FLAC-implementation], and the initial draft version of this document were originally developed by Josh Coalson. While many others have contributed since, this original effort is deeply appreciated. +

+
+
+

+FLAC形式、FLAC参照実装[FLAC-Implementation]、およびこのドキュメントの最初のドラフトバージョンは、もともとJosh Coalsonによって開発されました。それ以来、他の多くの人が貢献していますが、この当初の努力は深く感謝されています。 +

+
+
+
+
+
+Authors' Addresses +
+
+
+
+著者のアドレス +
+
+
+
+
+ 
+   Martijn van Beurden
+   Netherlands
+   Email: mvanb1@gmail.com
+
+
+
+
+
+ 
+   Andrew Weaver
+   Email: theandrewjw@gmail.com
+
+
+
+
+ + + diff --git a/html/rfc9674.html b/html/rfc9674.html new file mode 100644 index 000000000..d69a160f2 --- /dev/null +++ b/html/rfc9674.html @@ -0,0 +1,675 @@ + + + + + + RFC 9674 - Same-Origin Policy for the RPKI Repository Delta Protocol (RRDP) 日本語訳 + + + + + + + + + + + + +
+
+ + + +
+
+
+ + +
+
+
+ 
+Internet Engineering Task Force (IETF)                       J. Snijders
+Request for Comments: 9674                                        Fastly
+Updates: 8182                                              December 2024
+Category: Standards Track                                               
+ISSN: 2070-1721
+
+
+
+
+
+
+Same-Origin Policy for the RPKI Repository Delta Protocol (RRDP) +
+
+
+
+RPKIリポジトリデルタプロトコル（RRDP）の同性ポリシー +
+
+
+
+
+
+Abstract +
+
+
+
+概要 +
+
+
+
+
+

+This document describes a Same-Origin Policy (SOP) requirement for Resource Public Key Infrastructure (RPKI) Repository Delta Protocol (RRDP) servers and clients. Application of a SOP in RRDP client/ server communication isolates resources such as Delta and Snapshot files from different Repository Servers, reducing possible attack vectors. This document updates RFC 8182. +

+
+
+

+このドキュメントでは、リソース公開キーインフラストラクチャ（RPKI）リポジトリデルタプロトコル（RRDP）サーバーおよびクライアントの同性ポリシー（SOP）要件について説明します。RRDPクライアント/サーバー通信でのSOPのアプリケーションは、異なるリポジトリサーバーのデルタやスナップショットファイルなどのリソースを分離し、攻撃ベクトルの可能性を減らします。このドキュメントは、RFC 8182を更新します。 +

+
+
+
+
+
+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/rfc9674. +

+
+
+

+このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9674で取得できます。 +

+
+
+
+
+
+Copyright Notice +
+
+
+
+著作権表示 +
+
+
+
+
+

+Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. +

+
+
+

+著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。 +

+
+
+
+
+

+This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. +

+
+
+

+このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。 +

+
+
+
+
+
+Table of Contents +
+
+
+
+目次 +
+
+
+
+
+ 
+   1.  Introduction
+     1.1.  Requirements Language
+   2.  Implications of Cross-Origin Resource Requests in RRDP
+   3.  Changes to RFC 8182
+     3.1.  New Requirements for RRDP Repository Servers
+     3.2.  New Requirements for Relying Parties Using RRDP
+   4.  Deployability in the Internet's Current RPKI
+   5.  Security Considerations
+   6.  IANA Considerations
+   7.  References
+     7.1.  Normative References
+     7.2.  Informative References
+   Acknowledgements
+   Author's Address
+
+
+
+
+
+
+1. Introduction +
+
+
+
+1. はじめに +
+
+
+
+
+

+This document specifies a Same-Origin Policy (SOP) requirement for RPKI Repository Delta Protocol (RRDP) servers and clients. The SOP concept is a security mechanism to restrict how a document loaded from one origin can cause interaction with resources from another origin. See [RFC6454] for an overview of the concept of an "origin". Application of a SOP in RRDP client/server communication isolates resources such as Delta and Snapshot files from different Repository Servers, reducing possible attack vectors. Another way to avoid undesirable implications (as described in Section 2) would be for a future version of RRDP to use relative URIs instead of absolute URIs. This document updates [RFC8182]. +

+
+
+

+このドキュメントは、RPKIリポジトリデルタプロトコル（RRDP）サーバーおよびクライアントの同性ポリシー（SOP）要件を指定します。SOPの概念は、ある原点からロードされたドキュメントが別の起源からのリソースとの相互作用を引き起こす方法を制限するセキュリティメカニズムです。「起源」の概念の概要については、[RFC6454]を参照してください。RRDPクライアント/サーバー通信でのSOPのアプリケーションは、異なるリポジトリサーバーのデルタやスナップショットファイルなどのリソースを分離し、攻撃ベクトルの可能性を減らします。（セクション2で説明されているように）望ましくない意味を避ける別の方法は、RRDPの将来のバージョンが絶対的なURIの代わりに相対URIを使用することです。このドキュメントは[RFC8182]を更新します。 +

+
+
+
+
+
+1.1. Requirements Language +
+
+
+
+1.1. 要件言語 +
+
+
+
+
+

+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. +

+
+
+

+キーワード「必須」、「必要」、「必須」、「shall」、「shall」、「shill "of"、 "nove"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。 +

+
+
+
+
+
+2. Implications of Cross-Origin Resource Requests in RRDP +
+
+
+
+2. RRDPでのクロスオリジンリソース要求の意味 +
+
+
+
+
+

+The first RRDP specification did not explicitly disallow 'cross-origin' URI references from the Update Notification file (Section 3.5.1 of [RFC8182]) towards Delta (Section 3.5.3 of [RFC8182]) and Snapshot (Section 3.5.2 of [RFC8182]) files, and it was silent on the topic of HTTP Redirection (Section 15.4 of [RFC9110]). +

+
+
+

+最初のRRDP仕様は、デルタ（[RFC8182]のセクション3.5.3）およびスナップショット（セクション3.5.2のセクション3.5.3）に向けて、更新通知ファイル（[RFC8182]のセクション3.5.1）から「クロスオリジン」URI参照を明示的に禁止していませんでした。[RFC8182]）ファイル、およびHTTPリダイレクトのトピック（[RFC9110]のセクション15.4）については沈黙していました。 +

+
+
+
+
+

+The implication of cross-origin references in Update Notification files is that one Repository Server can reference RRDP resources on another Repository Server and in doing so inappropriately increase the resource consumption for both RRDP clients and the referenced Repository Server. An adversary could also employ cross-origin HTTP Redirects towards other Repository Servers, causing similar undesirable behavior. +

+
+
+

+更新通知ファイルにおけるクロスオリジン参照の意味は、1つのリポジトリサーバーが別のリポジトリサーバーでRRDPリソースを参照し、RRDPクライアントと参照されるリポジトリサーバーの両方のリソース消費を不適切に増やすことができることです。敵は、他のリポジトリサーバーに向けて、オリジンクロスHTTPリダイレクトを採用し、同様の望ましくない動作を引き起こす可能性があります。 +

+
+
+
+
+
+3. Changes to RFC 8182 +
+
+
+
+3. RFC 8182の変更 +
+
+
+
+
+

+To overcome the issue described in Section 2, RRDP Repository Servers and Clients MUST apply a Same-Origin Policy to both the URIs referenced in an Update Notification File and any HTTP Redirects. +

+
+
+

+セクション2で説明されている問題を克服するには、RRDPリポジトリサーバーとクライアントは、更新通知ファイルで参照されているURIとHTTPリダイレクトの両方に同様のオリジンポリシーを適用する必要があります。 +

+
+
+
+
+
+3.1. New Requirements for RRDP Repository Servers +
+
+
+
+3.1. RRDPリポジトリサーバーの新しい要件 +
+
+
+
+
+

+The following checklist items are added to Section 3.5.1.3 of [RFC8182]: +

+
+
+

+次のチェックリスト項目は、[RFC8182]のセクション3.5.1.3に追加されます。 +

+
+
+
+
+

+NEW +

+
+
+

+新しい +

+
+
+
+
+

+* The "uri" attribute in the snapshot element and optional delta elements MUST be part of the same origin (i.e., represent the same principal), meaning referenced URIs MUST have the same scheme, host, and port as the URI for the Update Notification File specified in the referring RRDP SIA AccessDescription. +

+
+
+

+* スナップショット要素とオプションのデルタ要素の「URI」属性は、同じ原点の一部でなければなりません（つまり、同じプリンシパルを表します）。参照RRDP SIA AccessDescriptionで指定されています。 +

+
+
+
+
+

+* The Repository Server MUST NOT respond with HTTP Redirects towards locations with an origin different from the origin of the Update Notification File specified in the referring RRDP SIA AccessDescription. +

+
+
+

+* リポジトリサーバーは、参照RRDP SIA AccessDescriptionで指定された更新通知ファイルの起源とは異なる原点を持つ場所にHTTPリダイレクトを使用して応答してはなりません。 +

+
+
+
+
+
+3.2. New Requirements for Relying Parties Using RRDP +
+
+
+
+3.2. RRDPを使用して当事者に依存するための新しい要件 +
+
+
+
+
+

+The following adds to Section 3.4.1 of [RFC8182]: +

+
+
+

+以下は、[RFC8182]のセクション3.4.1に追加されます。 +

+
+
+
+
+

+NEW +

+
+
+

+新しい +

+
+
+
+
+

+* The Relying Party MUST verify whether the "uri" attributes in the Update Notification File are of the same origin as the Update Notification File itself. If this verification fails, the file MUST be rejected and RRDP cannot be used; see Section 3.4.5 for considerations. Implementations SHOULD log a message when cross-origin referrals are detected. +

+
+
+

+* 頼る当事者は、更新通知ファイルの「URI」属性が更新通知ファイル自体と同じ起源であるかどうかを確認する必要があります。この検証が失敗した場合、ファイルを拒否する必要があり、RRDPを使用できません。考慮事項については、セクション3.4.5を参照してください。オリジンの紹介が検出されたときに、実装にメッセージを記録する必要があります。 +

+
+
+
+
+

+* The Relying Party MUST NOT follow HTTP Redirection that results from attempts to download Update Notification, Delta, and Snapshot files if the target origin is different from the origin of the Update Notification File specified in the referring RRDP SIA AccessDescription. If this verification fails, the RRDP session MUST be rejected and RRDP cannot be used; see Section 3.4.5 for considerations. Implementations SHOULD log a message when cross-origin redirects are detected. +

+
+
+

+* 頼る当事者は、ターゲットの原点が参照RRDP SIA AccessDescriptionで指定された更新通知ファイルの原点とは異なる場合、更新通知、Delta、およびSnapshotファイルをダウンロードしようとするHTTPリダイレクトに従ってはいけません。この検証が失敗した場合、RRDPセッションを拒否する必要があり、RRDPを使用できません。考慮事項については、セクション3.4.5を参照してください。クロスオリジンリダイレクトが検出された場合、実装はメッセージを記録する必要があります。 +

+
+
+
+
+
+4. Deployability in the Internet's Current RPKI +
+
+
+
+4. インターネットの現在のRPKIでの展開性 +
+
+
+
+
+

+Analyzing the [rpkiviews] archives for the period from April to September 2024, only one RRDP server (reached following the Trust Anchor Locators (TALs) of the five Regional Internet Registries) employed a same-origin HTTP redirect. In the period October 2021 - October 2024 no RRDP Repository Servers were observed that employed cross-origin URIs in Update Notification Files. +

+
+
+

+2024年4月から9月までの期間の[RPKiviews]アーカイブを分析すると、同様のHTTPリダイレクトを採用したRRDPサーバー（5つの地域インターネットレジストリのトラストアンカーロケーター（TALS）に続いて到達）のみが到達しました。2021年10月 - 2024年10月に、更新通知ファイルでクロスオリジンURIを使用したRRDPリポジトリサーバーは観察されませんでした。 +

+
+
+
+
+

+This means that imposing a requirement for the application of a Same-Origin Policy does not cause any existing commonly used RRDP Repository Server operations to become non-compliant. +

+
+
+

+これは、同じオーリジンポリシーを適用するための要件を課しても、既存の一般的に使用されるRRDPリポジトリサーバー操作が非準拠にならないことを意味します。 +

+
+
+
+
+
+5. Security Considerations +
+
+
+
+5. セキュリティに関する考慮事項 +
+
+
+
+
+

+This document addresses an oversight in the original RRDP specification: Cross-origin requests are detrimental as they allow one repository operator to increase resource consumption for other repository operators and RRDP clients. +

+
+
+

+このドキュメントは、元のRRDP仕様の監視に対処します。1つのリポジトリオペレーターが他のリポジトリオペレーターおよびRRDPクライアントのリソース消費を増やすことができるため、クロスオリジン要求は有害です。 +

+
+
+
+
+
+6. IANA Considerations +
+
+
+
+6. IANAの考慮事項 +
+
+
+
+
+

+This document has no IANA actions. +

+
+
+

+このドキュメントにはIANAアクションがありません。 +

+
+
+
+
+
+7. References +
+
+
+
+7. 参考文献 +
+
+
+
+
+
+7.1. Normative References +
+
+
+
+7.1. 引用文献 +
+
+
+
+
+ 
+   [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>.
+
+
+
+
+
+ 
+   [RFC6454]  Barth, A., "The Web Origin Concept", RFC 6454,
+              DOI 10.17487/RFC6454, December 2011,
+              <https://www.rfc-editor.org/info/rfc6454>.
+
+
+
+
+
+ 
+   [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>.
+
+
+
+
+
+ 
+   [RFC8182]  Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein,
+              "The RPKI Repository Delta Protocol (RRDP)", RFC 8182,
+              DOI 10.17487/RFC8182, July 2017,
+              <https://www.rfc-editor.org/info/rfc8182>.
+
+
+
+
+
+ 
+   [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
+              Ed., "HTTP Semantics", STD 97, RFC 9110,
+              DOI 10.17487/RFC9110, June 2022,
+              <https://www.rfc-editor.org/info/rfc9110>.
+
+
+
+
+
+
+7.2. Informative References +
+
+
+
+7.2. 参考引用 +
+
+
+
+
+ 
+   [rpkiviews]
+              Snijders, J., "rpkiviews", <https://www.rpkiviews.org>.
+
+
+
+
+
+
+Acknowledgements +
+
+
+
+謝辞 +
+
+
+
+
+

+The author wishes to thank Theo Buehler, Claudio Jeker, Alberto Leiva, Tim Bruijnzeels, Ties de Kock, Martin Hoffmann, and Mikhail Puzanov for their helpful feedback, comments, and implementation work. The author wishes to thank Keyur Patel, Meral Shirazipour, Niclas Comstedt, Dan Harkins, Erik Kline, Roman Danyliw, and Éric Vyncke for their review. +

+
+
+

+著者は、Theo Buehler、Claudio Jeker、Alberto Leiva、Tim Bruijnzeels、Ties de Kock、Martin Hoffmann、およびMikhail Puzanovに有益なフィードバック、コメント、実装作業に感謝したいと考えています。著者は、Keyur Patel、Meral Shirazipour、Niclas Comstedt、Dan Harkins、Erik Kline、Roman Danyliw、Eric Vynckeにレビューに感謝したいと考えています。 +

+
+
+
+
+
+Author's Address +
+
+
+
+著者の連絡先 +
+
+
+
+
+ 
+   Job Snijders
+   Fastly
+   Amsterdam
+   Netherlands
+   Email: job@fastly.com
+
+
+
+
+ + + diff --git a/html/rfc9683.html b/html/rfc9683.html new file mode 100644 index 000000000..7902de184 --- /dev/null +++ b/html/rfc9683.html @@ -0,0 +1,4600 @@ + + + + + + RFC 9683 - Remote Integrity Verification of Network Devices Containing Trusted Platform Modules 日本語訳 + + + + + + + + + + + + +
+
+ + + +
+
+
+ + +
+
+
+ 
+Internet Engineering Task Force (IETF)               G. C. Fedorkow, Ed.
+Request for Comments: 9683                        Juniper Networks, Inc.
+Category: Informational                                          E. Voit
+ISSN: 2070-1721                                                    Cisco
+                                                     J. Fitzgerald-McKay
+                                                National Security Agency
+                                                           December 2024
+
+
+
+
+
+
+Remote Integrity Verification of Network Devices Containing Trusted Platform Modules +
+
+
+
+信頼できるプラットフォームモジュールを含むネットワークデバイスのリモート整合性検証 +
+
+
+
+
+
+Abstract +
+
+
+
+概要 +
+
+
+
+
+

+This document describes a workflow for remote attestation of the integrity of firmware and software installed on network devices that contain Trusted Platform Modules (TPMs), as defined by the Trusted Computing Group (TCG), or equivalent hardware implementations that include the protected capabilities, as provided by TPMs. +

+
+
+

+このドキュメントでは、信頼できるコンピューティンググループ（TCG）によって定義されている信頼できるプラットフォームモジュール（TPM）を含むネットワークデバイスにインストールされているファームウェアとソフトウェアの整合性をリモート認証するためのワークフローについて説明します。TPMSによって提供されます。 +

+
+
+
+
+
+Status of This Memo +
+
+
+
+本文書の位置付け +
+
+
+
+
+

+This document is not an Internet Standards Track specification; it is published for informational purposes. +

+
+
+

+このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。 +

+
+
+
+
+

+This document is a product of the Internet 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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841. +

+
+
+

+このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。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/rfc9683. +

+
+
+

+このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9683で取得できます。 +

+
+
+
+
+
+Copyright Notice +
+
+
+
+著作権表示 +
+
+
+
+
+

+Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. +

+
+
+

+著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。 +

+
+
+
+
+

+This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. +

+
+
+

+このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。 +

+
+
+
+
+
+Table of Contents +
+
+
+
+目次 +
+
+
+
+
+ 
+   1.  Introduction
+     1.1.  Requirements Notation
+     1.2.  Terminology
+     1.3.  Document Organization
+     1.4.  Goals
+     1.5.  Description of Remote Integrity Verification (RIV)
+     1.6.  Solution Requirements
+     1.7.  Scope
+       1.7.1.  Out of Scope
+   2.  Solution Overview
+     2.1.  RIV Software Configuration Attestation Using TPM
+       2.1.1.  What Does RIV Attest?
+       2.1.2.  Notes on PCR Allocations
+     2.2.  RIV Keying
+     2.3.  RIV Information Flow
+     2.4.  RIV Simplifying Assumptions
+       2.4.1.  Reference Integrity Manifests (RIMs)
+       2.4.2.  Attestation Logs
+   3.  Standards Components
+     3.1.  Prerequisites for RIV
+       3.1.1.  Unique Device Identity
+       3.1.2.  Keys
+       3.1.3.  Appraisal Policy for Evidence
+     3.2.  Reference Model for Challenge-Response
+       3.2.1.  Transport and Encoding
+     3.3.  Centralized vs. Peer-to-Peer
+   4.  Privacy Considerations
+   5.  Security Considerations
+     5.1.  Keys Used in RIV
+     5.2.  Prevention of Spoofing and Person-in-the-Middle Attacks
+     5.3.  Replay Attacks
+     5.4.  Owner-Signed Keys
+     5.5.  Other Factors for Trustworthy Operation
+   6.  IANA Considerations
+   7.  Conclusion
+   8.  References
+     8.1.  Normative References
+     8.2.  Informative References
+   Appendix A.  Supporting Materials
+     A.1.  Using a TPM for Attestation
+     A.2.  Root of Trust for Measurement (RTM)
+     A.3.  Layering Model for Network Equipment Attester and Verifier
+     A.4.  Implementation Notes
+   Acknowledgements
+   Authors' Addresses
+
+
+
+
+
+
+1. Introduction +
+
+
+
+1. はじめに +
+
+
+
+
+

+There are many aspects to consider in fielding a trusted computing device, from operating systems to applications. Mechanisms to prove that a device installed at a customer's site is authentic (i.e., not counterfeit) and has been configured with authorized software, all as part of a trusted supply chain, are just a few of the many aspects that need to be considered concurrently to have confidence that a device is truly trustworthy. +

+
+
+

+オペレーティングシステムからアプリケーションまで、信頼できるコンピューティングデバイスをフィールドする際に考慮すべき多くの側面があります。顧客のサイトにインストールされているデバイスが本物であり（つまり、偽造ではない）、信頼できるサプライチェーンの一部として認定ソフトウェアで構成されていることを証明するメカニズムは、同時に考慮する必要がある多くの側面のほんの一部ですデバイスが本当に信頼できると確信すること。 +

+
+
+
+
+

+A generic architecture for remote attestation has been defined in [RFC9334]. Additionally, use cases for remotely attesting networking devices are discussed within Section 5 of [RATS-USECASES]. However, these documents do not provide sufficient guidance for network equipment vendors and operators to design, build, and deploy interoperable devices. +

+
+
+

+リモートの認証のための一般的なアーキテクチャは、[RFC9334]で定義されています。さらに、ネットワークデバイスをリモートで証明するためのユースケースについては、[rats-secases]のセクション5で説明します。ただし、これらのドキュメントでは、ネットワーク機器ベンダーとオペレーターが相互運用可能なデバイスを設計、構築、展開するのに十分なガイダンスを提供していません。 +

+
+
+
+
+

+The intent of this document is to provide such guidance. It does this by outlining the Remote Integrity Verification (RIV) problem and then by identifying the necessary elements to get the complete, scalable attestation procedure working with commercial networking products such as routers, switches, and firewalls. An underlying assumption is the availability within the device of a cryptoprocessor that is compatible with the Trusted Platform Module specifications [TPM-1.2] [TPM-2.0] to enable the trustworthy, remote assessment of the device's software and hardware. +

+
+
+

+このドキュメントの意図は、そのようなガイダンスを提供することです。これは、リモートの整合性検証（RIV）の問題を概説し、必要な要素を識別して、ルーター、スイッチ、ファイアウォールなどの商用ネットワーキング製品と連携する完全でスケーラブルな証明手順を取得することにより行います。根本的な仮定は、信頼できるプラットフォームモジュール仕様[TPM-1.2] [TPM-2.0]と互換性のある暗号プロセッサのデバイス内の可用性であり、デバイスのソフトウェアとハードウェアの信頼できるリモート評価を可能にします。 +

+
+
+
+
+
+1.1. Requirements Notation +
+
+
+
+1.1. 要件表記 +
+
+
+
+
+

+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. +

+
+
+

+「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。 +

+
+
+
+
+
+1.2. Terminology +
+
+
+
+1.2. 用語 +
+
+
+
+
+

+A number of terms are reused from [RFC9334]. These include Appraisal Policy for Evidence, Attestation Result, Attester, Evidence, Reference Value, Relying Party, Verifier, and Verifier Owner. +

+
+
+

+[RFC9334]から多くの用語が再利用されます。これらには、証拠、証明の結果、attester、証拠、参照値、依存者、検証者、および検証者の所有者に関する評価ポリシーが含まれます。 +

+
+
+
+
+

+Additionally, this document defines the following term: +

+
+
+

+さらに、このドキュメントは次の用語を定義します。 +

+
+
+
+
+

+Attestation: +

+
+
+

+証明： +

+
+
+
+
+

+The process of generating, conveying, and appraising claims, backed by evidence, about device trustworthiness characteristics, including supply chain trust, identity, device provenance, software configuration, device composition, compliance to test suites, functional and assurance evaluations, etc. +

+
+
+

+サプライチェーンの信頼、アイデンティティ、デバイスの起源、ソフトウェア構成、デバイスの構成、テストスイート、機能および保証評価など、デバイスの信頼性の特性について、証拠に裏付けられた主張を生成、伝達、および評価するプロセス。 +

+
+
+
+
+

+The goal of attestation is simply to assure an administrator or auditor that the device's configuration and software were authentic and unmodified when the device started. The determination of software authenticity is not prescribed in this document, but it's typically taken to mean a software image generated by an authority trusted by the administrator, such as the device manufacturer. +

+
+
+

+証明の目標は、デバイスの構成とソフトウェアがデバイスの開始時に本物であり、変更されていないことを管理者または監査人に保証することです。ソフトウェアの信頼性の決定はこのドキュメントでは規定されていませんが、通常、デバイスメーカーなどの管理者が信頼している当局によって生成されるソフトウェアイメージを意味すると考えられています。 +

+
+
+
+
+

+Within the context of the Trusted Computing Group (TCG), the scope of attestation is typically narrowed to describe the process by which an independent Verifier can obtain cryptographic proof as to the identity of the device in question, evidence of the integrity of the device's software that was loaded upon startup, and verification that the current configuration matches the intended configuration. For network equipment, a Verifier capability can be embedded in a Network Management Station, a posture collection server, or other network analytics tool (such as a software asset management solution, or a threat detection and mitigation tool, etc.). This document focuses on a specific subset of attestation tasks, defined here as Remote Integrity Verification (RIV), and informally referred to as attestation. RIV in this document takes a network-equipment-centric perspective that includes a set of protocols and procedures for determining whether a particular device was launched with authentic software, starting from Roots of Trust. While there are many ways to accomplish attestation, RIV sets out a specific set of protocols and tools that work in environments commonly found in network equipment. RIV does not cover other device characteristics that could be attested (e.g., geographic location or connectivity; see [RATS-USECASES]), although it does provide evidence of a secure infrastructure to increase the level of trust in other device characteristics attested by other means (e.g., by Entity Attestation Tokens [RATS-EAT]). +

+
+
+

+信頼できるコンピューティンググループ（TCG）のコンテキスト内で、実際には、独立した検証者が問題のデバイスのアイデンティティ、デバイスのソフトウェアの整合性の証拠に関して暗号化された証明を得ることができるプロセスを説明するために、認証の範囲が狭くなりますこれはスタートアップ時にロードされ、現在の構成が意図した構成と一致することを確認しました。ネットワーク機器の場合、ネットワーク管理ステーション、姿勢収集サーバー、またはその他のネットワーク分析ツール（ソフトウェア資産管理ソリューション、脅威検出および緩和ツールなど）に検証機能を埋め込むことができます。このドキュメントは、ここではリモート整合性検証（RIV）として定義され、非公式には証明と呼ばれる特定の証明タスクのサブセットに焦点を当てています。このドキュメントのRIVは、特定のデバイスが信頼のルーツから始まる本物のソフトウェアで起動されたかどうかを判断するための一連のプロトコルと手順を含むネットワークエクイプメント中心の視点を取得します。認証を達成するには多くの方法がありますが、RIVはネットワーク機器で一般的に見られる環境で機能する特定のプロトコルとツールのセットを設定します。RIVは、証明できる他のデバイスの特性をカバーしません（例：地理的位置や接続性; [rats-usecases]を参照）。（例えば、エンティティの証明トークン[rats-eat]）。 +

+
+
+
+
+

+In line with definitions found in [RFC9334], this document uses the term Endorser to refer to the role that signs identity and attestation certificates used by the Attester, while Reference Values are signed by a Reference Value Provider. Typically, the manufacturer of a network device would be accepted as both the Endorser and Reference Value Provider, although the choice is ultimately up to the Verifier Owner. +

+
+
+

+[RFC9334]で見つかった定義に沿って、このドキュメントでは、エンダーザーという用語を使用して、参照値は参照値プロバイダーによって署名されている間、Attesterが使用する証明書に署名する役割と証明証明書を参照します。通常、ネットワークデバイスのメーカーは、最終的には検証者の所有者次第ですが、[エンサーと参照価値プロバイダーの両方として受け入れられます。 +

+
+
+
+
+
+1.3. Document Organization +
+
+
+
+1.3. ドキュメント組織 +
+
+
+
+
+

+The remainder of this document is organized into several sections: +

+
+
+

+このドキュメントの残りの部分は、いくつかのセクションに編成されています。 +

+
+
+
+
+

+* The remainder of this section covers goals and requirements, plus a top-level description of RIV. +

+
+
+

+* このセクションの残りは、目標と要件に加えて、RIVのトップレベルの説明をカバーしています。 +

+
+
+
+
+

+* The Solution Overview section (Section 2) outlines how RIV works. +

+
+
+

+* ソリューションの概要セクション（セクション2）では、RIVの仕組みの概要を説明します。 +

+
+
+
+
+

+* The Standards Components section (Section 3) links components of RIV to normative standards. +

+
+
+

+* 標準コンポーネントセクション（セクション3）は、RIVのコンポーネントを規範的標準にリンクします。 +

+
+
+
+
+

+* The Privacy and Security Considerations sections (Sections 4 and 5) shows how specific features of RIV contribute to the trustworthiness of the Attestation Result. +

+
+
+

+* プライバシーとセキュリティの考慮事項セクション（セクション4および5）は、RIVの特定の特徴が認証結果の信頼性にどのように貢献するかを示しています。 +

+
+
+
+
+

+* Supporting material is in an appendix (Appendix A). +

+
+
+

+* サポート資料は付録（付録A）にあります。 +

+
+
+
+
+
+1.4. Goals +
+
+
+
+1.4. 目標 +
+
+
+
+
+

+Network operators benefit from a trustworthy attestation mechanism that provides assurance that their network comprises authentic equipment and has loaded software free of known vulnerabilities and unauthorized tampering. In line with the overall goal of assuring integrity, attestation can be used to assist in asset management, vulnerability and compliance assessment, plus configuration management. +

+
+
+

+ネットワークオペレーターは、ネットワークが本物の機器で構成され、既知の脆弱性や不正な改ざんのないソフトウェアをロードしたという保証を提供する信頼できる証明メカニズムの恩恵を受けます。完全性を保証するという全体的な目標に沿って、資産管理、脆弱性、コンプライアンス評価、および構成管理を支援するために証明を使用できます。 +

+
+
+
+
+

+The RIV attestation workflow outlined in this document is intended to meet the following high-level goals: +

+
+
+

+このドキュメントで概説されているRIVの証明ワークフローは、次の高レベルの目標を満たすことを目的としています。 +

+
+
+
+
+

+* Provable Device Identity - This specification requires that an Attester (i.e., the attesting device) includes a cryptographic identifier unique to each device. Effectively, this means that the device's TPM must be provisioned with this during the manufacturing cycle. +

+
+
+

+* 証明可能なデバイスのID-この仕様では、Attester（つまり、証明デバイス）には、各デバイスに固有の暗号化識別子が含まれることが必要です。事実上、これは、製造サイクル中にデバイスのTPMをこれでプロビジョニングする必要があることを意味します。 +

+
+
+
+
+

+* Software Inventory - Key goals are to identify the software release(s) installed on the Attester and to provide evidence that the software stored within hasn't been altered without authorization. +

+
+
+

+* ソフトウェアインベントリ - 重要な目標は、Attesterにインストールされたソフトウェアリリースを特定し、内部に保存されているソフトウェアが許可なしに変更されていないという証拠を提供することです。 +

+
+
+
+
+

+* Verifiability - Verification of the device's software and configuration shows that the software that the administrator authorized for use was actually launched. +

+
+
+

+* 検証可能性 - デバイスのソフトウェアと構成の検証は、管理者が使用することを許可したソフトウェアが実際に起動されたことを示しています。 +

+
+
+
+
+

+In addition, RIV is designed to operate either in a centralized environment, such as with a central authority that manages and configures a number of network devices, or "peer-to-peer", where network devices independently verify one another to establish a trust relationship. (See Section 3.3.) +

+
+
+

+さらに、RIVは、多くのネットワークデバイスを管理および構成する中央当局など、集中環境で動作するように設計されています。関係。（セクション3.3を参照してください。） +

+
+
+
+
+
+1.5. Description of Remote Integrity Verification (RIV) +
+
+
+
+1.5. リモート整合性検証（RIV）の説明 +
+
+
+
+
+

+Attestation requires two interlocking mechanisms between the Attester network device and the Verifier: +

+
+
+

+証明には、Attesterネットワークデバイスと検証器の間に2つの連動メカニズムが必要です。 +

+
+
+
+
+

+* Device Identity is the mechanism that provides trusted identity, which can reassure network managers that the specific devices they ordered from authorized manufacturers for attachment to their network are those that were installed and that they continue to be present in their network. As part of the mechanism for Device Identity, cryptographic proof of the manufacturer's identity is also provided. +

+
+
+

+* デバイスのアイデンティティは、信頼できるアイデンティティを提供するメカニズムであり、ネットワークへの添付のために認可されたメーカーから注文した特定のデバイスがインストールされたものであり、ネットワークに存在し続けることをネットワークマネージャーに安心させることができます。デバイスアイデンティティのメカニズムの一部として、メーカーのアイデンティティの暗号化された証明も提供されます。 +

+
+
+
+
+

+* Software Measurement is the mechanism that reports the state of mutable software components on the device and that can assure administrators that they have known, authentic software configured to run in their network. +

+
+
+

+* ソフトウェア測定は、デバイス上の可変ソフトウェアコンポーネントの状態を報告し、ネットワークで実行するように構成された本物のソフトウェアを知っている管理者に保証できるメカニズムです。 +

+
+
+
+
+

+By using these two interlocking mechanisms, RIV, which is a component in a chain of procedures, can assure a network operator that the equipment in their network can be reliably identified and that authentic software of a known version is installed on each device. Equipment in the network includes devices that make up the network itself, such as routers, switches, and firewalls. +

+
+
+

+これら2つのインターロックメカニズムを使用することにより、一連の手順のコンポーネントであるRIVは、ネットワークオペレーターにネットワーク内の機器を確実に識別できること、および既知のバージョンの本物のソフトウェアが各デバイスにインストールされていることを保証できます。ネットワーク内の機器には、ルーター、スイッチ、ファイアウォールなど、ネットワーク自体を構成するデバイスが含まれています。 +

+
+
+
+
+

+Software used to boot a device can be identified by a chain of measurements, anchored at the start by a Root of Trust for Measurement (RTM) (see Appendix A.2). An attestation function embedded in each stage, verified by the previous stage, measures the next stage and records the result in tamper-resistant storage. A measurement signifies the identity, integrity, and version of each software component registered with an Attester's TPM [TPM-1.2] [TPM-2.0] so that a subsequent verification stage can determine if the software installed is authentic, up-to-date, and free of tampering. +

+
+
+

+デバイスの起動に使用されるソフトウェアは、測定のための信頼のルート（RTM）によって開始時に固定された一連の測定によって識別できます（付録A.2を参照）。前の段階で検証された各段階に埋め込まれた証明関数は、次の段階を測定し、タンパー耐性ストレージの結果を記録します。測定は、AstesterのTPM [TPM-1.2] [TPM-2.0]に登録された各ソフトウェアコンポーネントのID、整合性、およびバージョンを意味します。改ざんされていません。 +

+
+
+
+
+

+RIV includes several major processes, which are split between the Attester and Verifier: +

+
+
+

+RIVにはいくつかの主要なプロセスが含まれています。これらには、AttesterとVerifierの間に分割されています。 +

+
+
+
+
+

+1. Generation of Evidence is the process whereby an Attester generates cryptographic proof (Evidence) of claims about device properties. In particular, the device identity and its software configuration are both of critical importance. +

+
+
+

+1. 証拠の生成とは、アテスターがデバイスプロパティに関する主張の暗号化された証明（証拠）を生成するプロセスです。特に、デバイスのIDとそのソフトウェア構成はどちらも非常に重要です。 +

+
+
+
+
+

+2. Device Identification refers to the mechanism assuring the Relying Party (ultimately, a network administrator) of the identities of devices, and the identities of their manufacturers, that make up their network. +

+
+
+

+2. デバイスの識別とは、ネットワークを構成するデバイスのアイデンティティの依存者（最終的にはネットワーク管理者）とメーカーのアイデンティティを保証するメカニズムを指します。 +

+
+
+
+
+

+3. Conveyance of Evidence reliably transports the collected Evidence from the Attester to a Verifier to allow a management station to perform a meaningful appraisal in Step 4. The transport is typically carried out via a management network. Although not required for reliable attestation, an encrypted channel may be used to provide integrity, authenticity, or confidentiality once attestation is complete. It should be noted that critical attestation evidence from the TPM is signed by a key known only to TPM, and is not dependent on encryption carried out as part of a reliable transport. +

+
+
+

+3. 証拠の伝達は、攻撃された証拠を、手順4で管理ステーションが有意義な評価を実行できるように、攻撃者から検証剤に確実に輸送されます。輸送は通常、管理ネットワークを介して実行されます。信頼できる証明には必要ありませんが、暗号化されたチャネルを使用して、完全性、信頼性、または機密性を提供することができます。TPMからの重要な証明の証拠は、TPMのみに知られているキーによって署名されており、信頼できる輸送の一部として実行される暗号化に依存していないことに注意する必要があります。 +

+
+
+
+
+

+4. Finally, appraisal of evidence occurs. This is the process of verifying the Evidence received by a Verifier from the Attester and using an Appraisal Policy to develop an Attestation Result, which is used to inform decision-making. In practice, this means comparing the Attester's measurements reported as Evidence with the device configuration expected by the Verifier. Subsequently, the Appraisal Policy for Evidence might match Evidence found against Reference Values (aka Golden Measurements), which represent the intended configured state of the connected device. +

+
+
+

+4. 最後に、証拠の評価が発生します。これは、アテスターから検証者が受け取った証拠を検証し、評価ポリシーを使用して意思決定を通知するために使用される証明結果を作成するプロセスです。実際には、これは、検証剤によって予想されるデバイス構成との証拠として報告されているAttesterの測定値を比較することを意味します。その後、証拠の評価ポリシーは、接続されたデバイスの意図した構成状態を表す基準値（別名ゴールデン測定）に対して見つかった証拠と一致する可能性があります。 +

+
+
+
+
+

+All implementations supporting this RIV specification require the support of the following three technologies: +

+
+
+

+このRIV仕様をサポートするすべての実装には、次の3つのテクノロジーのサポートが必要です。 +

+
+
+
+
+

+1. Identity: Device identity in RIV is based on Device Identity (DevID) defined by IEEE Std 802.1AR [IEEE-802-1AR], coupled with careful supply-chain management by the manufacturer. The Initial DevID (IDevID) certificate contains a statement by the manufacturer that establishes the identity of the device as it left the factory. Some applications with a more complex post-manufacture supply chain (e.g., value added resellers), or with different privacy concerns, may want to use alternative mechanisms for platform authentication (for example, TCG Platform Certificates [PLATFORM-CERTS] or post-manufacture installation of Local DevID (LDevID)). +

+
+
+

+1. ID：RIVのデバイスIDは、IEEE STD 802.1AR [IEEE-802-1AR]によって定義されたデバイスID（Devid）に基づいており、メーカーによる慎重なサプライチェーン管理と組み合わされています。初期Devid（IDEVID）証明書には、工場を離れたときにデバイスの身元を確立するメーカーによるステートメントが含まれています。より複雑な製造後のサプライチェーン（バリューアドレスリセラーなど）、またはさまざまなプライバシーの懸念を伴う一部のアプリケーションは、プラットフォーム認証に代替メカニズムを使用することをお勧めします（たとえば、TCGプラットフォーム証明書[プラットフォーム洞窟]または製造後の製造後ローカルdevid（ldevid）のインストール）。 +

+
+
+
+
+

+2. Platform attestation provides evidence of configuration of software elements present in the device. This form of attestation can be implemented with TPM Platform Configuration Registers (PCRs) and Quote and Log mechanisms, which provide cryptographically authenticated evidence to report what software was started on the device through the boot cycle. Successful attestation requires an unbroken chain from a boot-time Root of Trust through all layers of software needed to bring the device to an operational state, in which each stage computes the hash of components of the next stage, then updates the attestation log and the TPM. The TPM can then report the hashes of all the measured hashes as signed evidence called a Quote (see Appendix A.1 for an overview of TPM operation or [TPM-1.2] and [TPM-2.0] for many more details). +

+
+
+

+2. プラットフォームの証明は、デバイスに存在するソフトウェア要素の構成の証拠を提供します。この形式の証明は、TPMプラットフォーム構成レジスタ（PCR）と引用およびログメカニズムを使用して実装できます。このメカニズムは、ブートサイクルを通じてデバイスで開始されたソフトウェアを報告する暗号化された証拠を提供します。成功した証明には、デバイスを運用状態にするために必要なすべてのレイヤーのすべてのレイヤーを介して、信頼のブートタイムルートからの途切れないチェーンが必要です。各段階では、次の段階のコンポーネントのハッシュを計算し、証明ログとTPM。TPMは、引用と呼ばれる署名された証拠として測定されたすべてのハッシュのハッシュを報告できます（TPM操作の概要については、[TPM-1.2]および[TPM-2.0]の詳細については、付録A.1を参照）。 +

+
+
+
+
+

+3. Signed Reference Values (aka reference integrity measurements) must be conveyed from the Reference Value Provider (the entity accepted as the software authority, often the manufacturer of the network device) to the Verifier. +

+
+
+

+3. 署名された参照値（別名参照整合性測定）は、参照値プロバイダー（ソフトウェア機関として受け入れられているエンティティ、しばしばネットワークデバイスの製造業者）から検証器に伝える必要があります。 +

+
+
+
+
+
+1.6. Solution Requirements +
+
+
+
+1.6. 解決策要件 +
+
+
+
+
+

+RIV must address the "Lying Endpoint" problem, in which malicious software on an endpoint may subvert the intended function and also prevent the endpoint from reporting its compromised status. (See Section 5 for further Security Considerations.) +

+
+
+

+RIVは、エンドポイント上の悪意のあるソフトウェアが意図した関数を破壊し、エンドポイントが侵害されたステータスを報告するのを防ぐ可能性がある「横になっているエンドポイント」の問題に対処する必要があります。（さらなるセキュリティに関する考慮事項については、セクション5を参照してください。） +

+
+
+
+
+

+RIV attestation is designed to be simple to deploy at scale. RIV should work "out of the box" as far as possible, that is, with the fewest possible provisioning steps or configuration databases needed at the end user's site. Network equipment is often required to "self-configure", to reliably reach out without manual intervention to prove its identity and operating posture, then download its own configuration, a process which precludes pre-installation configuration. See [RFC8572] for an example of Secure Zero Touch Provisioning (SZTP). +

+
+
+

+RIVの証明は、大規模な展開が簡単になるように設計されています。RIVは、可能な限り「箱から出して」作業する必要があります。つまり、エンドユーザーのサイトで必要な可能性のあるプロビジョニングステップまたは構成データベースが必要です。ネットワーク機器は、多くの場合、「自己構成」し、そのアイデンティティと動作姿勢を証明するために手動介入なしで確実に手を差し伸べ、その後、独自の構成をダウンロードするために必要です。安全なゼロタッチプロビジョニング（SZTP）の例については、[RFC8572]を参照してください。 +

+
+
+
+
+
+1.7. Scope +
+
+
+
+1.7. 範囲 +
+
+
+
+
+

+The need for assurance of software integrity, addressed by Remote Attestation, is a very general problem that could apply to most network-connected computing devices. However, this document includes several assumptions that limit the scope to network equipment (e.g., routers, switches, and firewalls): +

+
+
+

+リモートの証明によって対処されるソフトウェアの整合性を保証する必要性は、ほとんどのネットワーク接続コンピューティングデバイスに適用できる非常に一般的な問題です。ただし、このドキュメントには、ネットワーク機器（例：ルーター、スイッチ、ファイアウォールなど）に範囲を制限するいくつかの仮定が含まれています。 +

+
+
+
+
+

+* This solution is for use in non-privacy-preserving applications (for example, networking or industrial Internet of Things (IoT) applications), which avoids the need for a Privacy Certification Authority (also called an Attestation CA) for Attestation Keys (AKs) [AIK-ENROLL] or TCG Platform Certificates [PLATFORM-CERTS]. +

+
+
+

+* このソリューションは、非プリバシーを提供するアプリケーション（たとえば、ネットワーキングや産業用モノのインターネット（IoT）アプリケーション）で使用するためのものであり、証明キー（AK）のためのプライバシー認証局（ATSETATIATIAN CAとも呼ばれます）の必要性を回避します。[AIK-Enroll]またはTCGプラットフォーム証明書[プラットフォームキャット]。 +

+
+
+
+
+

+* This document assumes network protocols that are common in network equipment such as YANG [RFC7950] and Network Configuration Protocol (NETCONF) [RFC6241], but not generally used in other applications. +

+
+
+

+* このドキュメントでは、Yang [RFC7950]やネットワーク構成プロトコル（NetConf）[RFC6241]などのネットワーク機器で一般的なネットワークプロトコルを想定していますが、他のアプリケーションでは一般的には使用されていません。 +

+
+
+
+
+

+* The approach outlined in this document mandates the use of a TPM [TPM-1.2] [TPM-2.0] or a compatible cryptoprocessor. +

+
+
+

+* このドキュメントで概説されているアプローチでは、TPM [TPM-1.2] [TPM-2.0]または互換性のある暗号化プロセッサの使用が義務付けられています。 +

+
+
+
+
+
+1.7.1. Out of Scope +
+
+
+
+1.7.1. 範囲外 +
+
+
+
+
+

+Run-Time Attestation: +

+
+
+

+ランタイムの証明： +

+
+
+
+
+

+The Linux Integrity Measurement Architecture [IMA] attests each process launched after a device is started (and is in scope for RIV in general), but continuous run-time attestation of Linux or other multi-threaded operating system processes after the OS has started considerably expands the scope of the problem. Many researchers are working on that problem, but this document defers the problem of continuous, in-memory run-time attestation. +

+
+
+

+Linux Integrity測定アーキテクチャ[IMA]は、デバイスの開始後に起動した各プロセスを証明しています（および一般的にRIVの範囲にあります）が、OSがかなり開始した後、Linuxまたはその他のマルチスレッドオペレーティングシステムプロセスの継続的な実行時間証明問題の範囲を拡大します。多くの研究者がその問題に取り組んでいますが、この文書は、継続的でメモリのランタイムの証明の問題を扱います。 +

+
+
+
+
+

+Multi-Vendor Embedded Systems: +

+
+
+

+マルチベンダー埋め込みシステム： +

+
+
+
+
+

+Additional coordination would be needed for devices that themselves comprise hardware and software from multiple vendors and are integrated by the end user. Although out of scope for this document, these issues are accommodated in [RFC9334]. +

+
+
+

+複数のベンダーからのハードウェアとソフトウェアを構成し、エンドユーザーによって統合されているデバイスには、追加の調整が必要です。この文書の範囲外ですが、これらの問題は[RFC9334]に対応しています。 +

+
+
+
+
+

+Processor Sleep Modes: +

+
+
+

+プロセッサスリープモード： +

+
+
+
+
+

+Network equipment typically does not "sleep", so sleep and hibernate modes are not considered. Although out of scope for RIV in this document, TCG specifications do encompass sleep and hibernate states, which could be incorporated into remote attestation for network equipment in the future, given a compelling need. +

+
+
+

+ネットワーク機器は通常「睡眠」ではないため、睡眠モードと冬眠モードは考慮されません。このドキュメントではRIVの範囲外ですが、TCG仕様には睡眠と冬眠状態が含まれます。これは、将来的には、将来のネットワーク機器のリモート証明書に組み込まれる可能性があります。 +

+
+
+
+
+

+Virtualization and Containerization: +

+
+
+

+仮想化とコンテナ化： +

+
+
+
+
+

+In a non-virtualized system, the host OS is responsible for measuring each user-space file or process throughout the operational lifetime of the system. For virtualized systems, the host OS must verify the hypervisor, but then the hypervisor must manage its own chain of trust through the virtual machine. Virtualization and containerization technologies are increasingly used in network equipment, but are not considered in this document. +

+
+
+

+非仮想化システムでは、ホストOSは、システムの運用寿命を通じて各ユーザースペースファイルまたはプロセスを測定する責任があります。仮想化システムの場合、ホストOSはハイパーバイザーを検証する必要がありますが、ハイパーバイザーは仮想マシンを介して独自の信頼チェーンを管理する必要があります。仮想化およびコンテナ化技術は、ネットワーク機器でますます使用されていますが、このドキュメントでは考慮されていません。 +

+
+
+
+
+
+2. Solution Overview +
+
+
+
+2. 解決策の概要 +
+
+
+
+
+
+2.1. RIV Software Configuration Attestation Using TPM +
+
+
+
+2.1. TPMを使用したRIVソフトウェア構成の証明 +
+
+
+
+
+

+RIV Attestation is a process that can be used to determine the identity of software running on a specifically identified device. The Remote Attestation steps of Section 1.5 are split into two phases as shown in Figure 1: +

+
+
+

+RIVの証明は、具体的に特定されたデバイスで実行されているソフトウェアのIDを決定するために使用できるプロセスです。図1に示すように、セクション1.5のリモート証明手順は2つのフェーズに分割されています。 +

+
+
+
+
+

+* During system startup, or Boot Phase, each distinct software object is "measured" by the Attester. The object's identity, hash (i.e., cryptographic digest), and version information are recorded in a log. Hashes are also extended into the TPM (see Appendix A.1 for more on extending hashes) in a way that can be used to validate the log entries. The measurement process generally follows the layered chain-of-trust model used in Measured Boot, where each stage of the system measures the next one, and extends its measurement into the TPM, before launching it. See Section 3.2 of [RFC9334], "Layered Attestation Environments", for an architectural definition of this model. +

+
+
+

+* システムスタートアップ、またはブートフェーズ中、各個別のソフトウェアオブジェクトは、アテスターによって「測定」されます。オブジェクトのアイデンティティ、ハッシュ（つまり、暗号化ダイジェスト）、およびバージョン情報はログに記録されます。ハッシュは、ログエントリの検証に使用できる方法で、TPM（拡張ハッシュの詳細については付録A.1を参照）に拡張されます。測定プロセスは、一般に、測定されたブートで使用される層状のトラストチェーンモデルに従います。ここで、システムの各段階が次の段階を測定し、測定をTPMに拡張してから起動します。このモデルのアーキテクチャの定義については、[RFC9334]のセクション3.2 [階層化された証明環境]を参照してください。 +

+
+
+
+
+

+* Once the device is running and has operational network connectivity, verification can take place. A separate Verifier, running in its own trusted environment, will interrogate the network device to retrieve the logs and a copy of the digests collected by hashing each software object, signed by an attestation private key secured by, but never released by, the TPM. The YANG model described in [RFC9684] facilitates this operation. +

+
+
+

+* デバイスが実行され、運用上のネットワーク接続があると、検証が行われます。独自の信頼できる環境で実行される別の検証者は、ネットワークデバイスを尋問して、各ソフトウェアオブジェクトをハッシュすることによって収集されたダイジェストのコピーを取得します。[RFC9684]に記載されているYangモデルは、この操作を促進します。 +

+
+
+
+
+

+The result is that the Verifier can verify the device's identity by checking the subject [RFC5280] and signature of the certificate containing the TPM's attestation public key. The Verifier can then verify the log's correctness by accumulating all the hashes in the log and comparing that to the signed digests from the TPM. From there, the Verifier can validate the launched software by comparing the digests in the log with Reference Values. +

+
+
+

+その結果、検証者は、被験者[RFC5280]をチェックし、TPMの証明公開キーを含む証明書の署名をチェックすることにより、デバイスのIDを検証できます。次に、検証剤は、ログ内のすべてのハッシュを蓄積し、TPMからの署名されたダイジェストと比較することにより、ログの正確性を検証できます。そこから、検証者は、ログ内のダイジェストを参照値と比較することにより、起動されたソフトウェアを検証できます。 +

+
+
+
+
+

+It should be noted that attestation and identity are inextricably linked; signed Evidence that a particular version of software was loaded is of little value without cryptographic proof of the identity of the Attester producing the Evidence. +

+
+
+

+証明とアイデンティティは密接にリンクされていることに注意する必要があります。特定のバージョンのソフトウェアがロードされたという署名された証拠は、証拠を作成しているアテスターのアイデンティティの暗号化された証拠なしではほとんど価値がありません。 +

+
+
+
+
+ 
+       +-------------------------------------------------------+
+       | +---------+    +--------+   +--------+    +---------+ |
+       | |UEFI BIOS|--->| Loader |-->| Kernel |--->|Userland | |
+       | +---------+    +--------+   +--------+    +---------+ |
+       |     |            |           |                        |
+       |     |            |           |                        |
+       |     +------------+-----------+-+                      |
+       |                    Boot Phase  |                      |
+       |                                V                      |
+       |                            +--------+                 |
+       |                            |  TPM   |                 |
+       |                            +--------+                 |
+       |   Router                       |                      |
+       +--------------------------------|----------------------+
+                                        |
+                                        |  Verification Phase
+                                        |    +-----------+
+                                        +--->| Verifier  |
+                                             +-----------+
+
+       Reset---------------flow-of-time-during-boot...--------->
+
+
+
+
+
+

+Figure 1: Layered RIV Attestation Model +

+
+
+

+図1：層状のRIV証明モデル +

+
+
+
+
+

+In the Boot Phase, measurements are "extended", or hashed, into the TPM as processes start, which result in the TPM containing hashes of all the measured hashes. Later, once the system is operational, signed digests are retrieved from the TPM during the Verification Phase for off-box analysis. +

+
+
+

+ブートフェーズでは、プロセスが開始されると、測定値がTPMに「拡張」またはハッシュされます。これにより、TPMにはすべての測定ハッシュのハッシュが含まれます。その後、システムが動作すると、署名されたダイジェストは、オフボックス分析のために検証フェーズ中にTPMから取得されます。 +

+
+
+
+
+
+2.1.1. What Does RIV Attest? +
+
+
+
+2.1.1. RIVは何を証明していますか？ +
+
+
+
+
+

+TPM attestation is focused on PCRs, but those registers are only vehicles for certifying accompanying Evidence conveyed in log entries. It is the hashes in log entries that are extended into PCRs, where the final PCR values can be retrieved in the form of a structure called a Quote, which is signed by an AK known only to the TPM. The use of multiple PCRs serves only to provide some independence between different classes of object so that one class of objects can be updated without changing the extended hash for other classes. Although PCRs can be used for any purpose, this section outlines the objects within the scope of this document that may be extended into the TPM. +

+
+
+

+TPMの証明はPCRSに焦点を当てていますが、これらのレジスタは、ログエントリで伝えられる添付の証拠を証明するための手段のみです。PCRSに拡張されたのは、ログエントリのハッシュであり、最終的なPCR値を引用と呼ばれる構造の形で取得できます。複数のPCRの使用は、異なるクラスのオブジェクト間である程度の独立性を提供するためだけに機能し、他のクラスの拡張ハッシュを変更せずに1つのクラスのオブジェクトを更新できます。PCRはあらゆる目的に使用できますが、このセクションでは、TPMに拡張される可能性のあるこのドキュメントの範囲内のオブジェクトの概要を説明します。 +

+
+
+
+
+

+In general, assignment of measurements to PCRs is a policy choice made by the device manufacturer, selected to independently attest three classes of object: +

+
+
+

+一般に、PCRSへの測定の割り当ては、デバイスメーカーが作成したポリシーの選択であり、3つのクラスのオブジェクトを独立して証明するように選択されました。 +

+
+
+
+
+

+Code: +

+
+
+

+コード： +

+
+
+
+
+

+Instructions to be executed by a CPU. +

+
+
+

+CPUによって実行される指示。 +

+
+
+
+
+

+Configuration: +

+
+
+

+構成： +

+
+
+
+
+

+Many devices offer numerous options controlled by non-volatile configuration variables that can impact the device's security posture. These settings may have vendor defaults, but often can be changed by administrators, who may want to verify via attestation that the operational state of the settings match their intended state. +

+
+
+

+多くのデバイスは、デバイスのセキュリティ姿勢に影響を与える可能性のある不揮発性構成変数によって制御される多数のオプションを提供しています。これらの設定にはベンダーのデフォルトがある場合がありますが、多くの場合、設定の運用状態が意図した状態と一致することを証明して検証したい管理者によって変更される可能性があります。 +

+
+
+
+
+

+Credentials: +

+
+
+

+資格： +

+
+
+
+
+

+Administrators may wish to verify via attestation that public keys and credentials outside the Root of Trust have not been subject to unauthorized tampering. (By definition, keys protecting the Root of Trust can't be verified independently.) +

+
+
+

+管理者は、信頼のルート外のパブリックキーと資格情報が不正な改ざんの影響を受けていないことを証明されていることを確認することをお勧めします。（定義上、信頼の根を保護するキーは独立して検証することはできません。） +

+
+
+
+
+

+The "TCG PC Client Specific Platform Firmware Profile Specification" [PC-CLIENT-BIOS-TPM-2.0] details what is to be measured during the Boot Phase of platform startup using a Unified Extensible Firmware Interface (UEFI) BIOS (<www.uefi.org>), but the goal is simply to measure every bit of code executed in the process of starting the device, along with any configuration information related to security posture, leaving no gap for unmeasured code to remain undetected and potentially subverting the chain. +

+
+
+

+「TCG PCクライアント固有のプラットフォームファームウェアプロファイル仕様」[PC-Client-BIOS-TPM-2.0]は、統一された拡張可能なファームウェアインターフェイス（UEFI）BIOSを使用して、プラットフォームスタートアップのブートフェーズで測定するものを詳述します（<www.uefi.org>）、しかし、目標は、デバイスを起動するプロセスで実行されたすべてのコードを、セキュリティ姿勢に関連する構成情報を測定することです。 +

+
+
+
+
+

+For devices using a UEFI BIOS, [PC-CLIENT-BIOS-TPM-2.0] and [PC-CLIENT-EFI-TPM-1.2] give detailed normative requirements for PCR usage. For other platform architectures, where TCG normative requirements currently do not exist, Table 1 gives non-normative guidance for PCR assignment that generalizes the specific details of [PC-CLIENT-BIOS-TPM-2.0]. +

+
+
+

+UEFI BIOSを使用したデバイスの場合、[PC-Client-BIOS-TPM-2.0]および[PC-Client-EFI-TPM-1.2]は、PCR使用に関する詳細な規範的要件を提供します。TCG規範要件が現在存在しない他のプラットフォームアーキテクチャの場合、表1は、[PC-Client-Bios-Bios-TPM-2.0]の特定の詳細を一般化するPCR割り当ての非規範的なガイダンスを示します。 +

+
+
+
+
+

+By convention, most PCRs are assigned in pairs, with the even-numbered PCR used to measure executable code and the odd-numbered PCR used to measure whatever data and configuration are associated with that code. It is important to note that each PCR may contain results from dozens (or even thousands) of individual measurements. +

+
+
+

+慣習により、ほとんどのPCRはペアで割り当てられ、均等なPCRは実行可能性コードを測定するために使用され、そのコードに関連付けられているデータと構成を測定するために使用される奇数のPCRが使用されます。各PCRには、個々の測定値の数十（または数千）の結果が含まれている場合があることに注意することが重要です。 +

+
+
+
+
+ 
+   +===========================================+======================+
+   |                                           | Assigned PCR #       |
+   +===========================================+======+===============+
+   | Function                                  | Code | Configuration |
+   +===========================================+======+===============+
+   | Firmware Static Root of Trust (i.e.,      | 0    | 1             |
+   | initial boot firmware and drivers)        |      |               |
+   +-------------------------------------------+------+---------------+
+   | Drivers and initialization for optional   | 2    | 3             |
+   | or add-in devices                         |      |               |
+   +-------------------------------------------+------+---------------+
+   | OS loader code and configuration (i.e.,   | 4    | 5             |
+   | the code launched by firmware) to load an |      |               |
+   | operating system kernel.  These PCRs      |      |               |
+   | record each boot attempt, and an          |      |               |
+   | identifier for where the loader was found |      |               |
+   +-------------------------------------------+------+---------------+
+   | Vendor-specific measurements during boot  | 6    | 6             |
+   +-------------------------------------------+------+---------------+
+   | Secure Boot Policy.  This PCR records     |      | 7             |
+   | keys and configuration used to validate   |      |               |
+   | the OS loader                             |      |               |
+   +-------------------------------------------+------+---------------+
+   | Measurements made by the OS loader (e.g., | 8    | 9             |
+   | GRUB2 for Linux)                          |      |               |
+   +-------------------------------------------+------+---------------+
+   | Measurements made by OS (e.g., Linux IMA) | 10   | 10            |
+   +-------------------------------------------+------+---------------+
+
+
+
+
+
+

+Table 1: Attested Objects +

+
+
+

+表1：証明されたオブジェクト +

+
+
+
+
+
+2.1.2. Notes on PCR Allocations +
+
+
+
+2.1.2. PCR割り当てに関するメモ +
+
+
+
+
+

+It is important to recognize that PCR[0] is critical. The first measurement into PCR[0] is taken by the Root of Trust for Measurement, which is code that, by definition, cannot be verified by measurement. This measurement establishes the chain of trust for all subsequent measurements. If the PCR[0] measurement cannot be trusted, the validity of the entire chain is called into question. +

+
+
+

+PCR [0]が重要であることを認識することが重要です。PCR [0]への最初の測定は、測定のために信頼のルートによって取得されます。これは、定義上、測定では検証できないコードです。この測定により、その後のすべての測定の信頼の連鎖が確立されます。PCR [0]測定値を信頼できない場合、チェーン全体の有効性が疑問視されます。 +

+
+
+
+
+

+Distinctions between PCR[0], PCR[2], PCR[4], and PCR[8] are summarized below: +

+
+
+

+PCR [0]、PCR [2]、PCR [4]、およびPCR [8]の区別を以下にまとめます。 +

+
+
+
+
+

+PCR[0] +

+
+
+

+PCR [0] +

+
+
+
+
+

+typically represents a consistent view of rarely changed boot components of the host platform, which allows Attestation policies to be defined using the less changeable components of the transitive trust chain. This PCR typically provides a consistent view of the platform regardless of user-selected options. +

+
+
+

+通常、ホストプラットフォームのめったに変更されていないブートコンポーネントの一貫したビューを表します。これにより、推移的な信頼チェーンのあまり変化しないコンポーネントを使用して証明ポリシーを定義できます。このPCRは通常、ユーザーが選択したオプションに関係なく、プラットフォームの一貫したビューを提供します。 +

+
+
+
+
+

+PCR[2] +

+
+
+

+PCR [2] +

+
+
+
+
+

+is intended to represent a "user-configurable" environment where the user has the ability to alter the components that are measured into PCR[2]. This is typically done by adding adapter cards, etc., into user-accessible Peripheral Component Interconnect (PCI) or other slots. In UEFI systems, these devices may be configured by Option ROMs measured into PCR[2] and executed by the UEFI BIOS. +

+
+
+

+ユーザーがPCRに測定されるコンポーネントを変更する機能を持つ「ユーザー構成可能な」環境を表すことを目的としています[2]。これは通常、アダプターカードなどをユーザーアクセス可能な周辺コンポーネントインターコネクト（PCI）またはその他のスロットに追加することによって行われます。UEFIシステムでは、これらのデバイスは、PCR [2]に測定され、UEFI BIOSによって実行されるオプションROMによって構成されてもよい。 +

+
+
+
+
+

+PCR[4] +

+
+
+

+PCR [4] +

+
+
+
+
+

+is intended to represent the software that manages the transition between the platform's pre-OS start and the state of a system with the OS present. This PCR, along with PCR[5], identifies the initial OS loader (e.g., GRUB for Linux). +

+
+
+

+プラットフォームのPre-OSスタートとOSが存在するシステムの状態との間の移行を管理するソフトウェアを表すことを目的としています。このPCRは、PCR [5]とともに、初期OSローダー（LinuxのGrubなど）を識別します。 +

+
+
+
+
+

+PCR[8] +

+
+
+

+PCR [8] +

+
+
+
+
+

+is used by the OS loader (e.g., GRUB) to record measurements of the various components of the operating system. +

+
+
+

+OSローダー（GRUBなど）で使用され、オペレーティングシステムのさまざまなコンポーネントの測定値を記録します。 +

+
+
+
+
+

+Although [PC-CLIENT-BIOS-TPM-2.0] specifies the use of the first eight PCRs very carefully to ensure interoperability among multiple UEFI BIOS vendors, it should be noted that embedded software vendors may have considerably more flexibility. Verifiers typically need to know which log entries are consequential and which are not (possibly controlled by local policies), but the Verifier may not need to know what each log entry means or why it was assigned to a particular PCR. Designers must recognize that some PCRs may cover log entries that a particular Verifier considers critical and other log entries that are not considered important, so differing PCR values may not on their own constitute a check for authenticity. For example, in a UEFI system, some administrators may consider booting an image from a removable drive, something recorded in a PCR, to be a security violation, while others might consider that operation to be an authorized recovery procedure. +

+
+
+

+[PC-Client-BIOS-TPM-2.0]は、複数のUEFI BIOSベンダー間の相互運用性を確保するために、最初の8つのPCRの使用を非常に慎重に指定していますが、組み込まれたソフトウェアベンダーはかなり柔軟性があることに注意する必要があります。Verifiersは通常、どのログエントリが結果的であり、どのログエントリではないかを知る必要があります（おそらくローカルポリシーによって制御されます）が、検証者は、各ログエントリが何を意味するのか、なぜ特定のPCRに割り当てられたのかを知る必要がない場合があります。設計者は、特定の検証者が重要と見なされない他のログエントリを考慮するログエントリをカバーする場合があるため、PCR値が異なる場合があることを認識しなければならないため、PCR値が異なる場合があります。たとえば、UEFIシステムでは、一部の管理者は、PCRに記録されたリムーバブルドライブから画像を起動することを検討することを検討する場合があります。 +

+
+
+
+
+

+Designers may allocate particular events to specific PCRs in order to achieve a particular objective with local attestation (e.g., allowing a procedure to execute, or releasing a particular decryption key, only if a given PCR is in a given state). It may also be important to designers to consider whether streaming notification of PCR updates is required (see [RATS-NET-DEV-SUB]). Specific log entries can only be validated if the Verifier receives every log entry affecting the relevant PCR, so (for example) a designer might want to separate rare, high-value events, such as configuration changes, from high-volume, routine measurements such as IMA logs [IMA]. +

+
+
+

+設計者は、特定のイベントを特定のPCRに割り当てることができます。特定の目的をローカルの証明で達成することができます（たとえば、特定のPCRが特定の状態にある場合にのみ、特定の復号化キーを実行またはリリースする手順を許可します）。また、設計者にとって、PCR更新のストリーミング通知が必要かどうかを検討することも重要かもしれません（[rats-net-dev-sub]を参照）。特定のログエントリは、検証者が関連するPCRに影響を与えるすべてのログエントリを受信した場合にのみ検証できます。たとえば、設計者は、構成変更など、大量の日常的な測定値から、希少な高価値のイベントを分離したい場合があります。IMAがログするように[IMA]。 +

+
+
+
+
+
+2.2. RIV Keying +
+
+
+
+2.2. RIVキーイング +
+
+
+
+
+

+RIV attestation relies on two credentials: +

+
+
+

+RIVの証明は、2つの資格情報に依存しています。 +

+
+
+
+
+

+* An identity key pair and matching certificate is required to certify the identity of the Attester itself. RIV specifies the use of an IEEE 802.1AR DevID [IEEE-802-1AR] that is signed by the device manufacturer and contains the device serial number. This requirement goes slightly beyond 802.1AR; see Section 2.4 for notes. +

+
+
+

+* Attester自体の身元を証明するには、IDキーペアとマッチング証明書が必要です。RIVは、デバイスメーカーが署名し、デバイスのシリアル番号を含むIEEE 802.1AR Devid [IEEE-802-1AR]の使用を指定します。この要件は802.1ARをわずかに超えています。メモについては、セクション2.4を参照してください。 +

+
+
+
+
+

+* An Attestation key pair and matching certificate is required to sign the Quote generated by the TPM to report evidence of software configuration. +

+
+
+

+* ソフトウェア構成の証拠を報告するために、TPMによって生成された見積もりに署名するには、証明キーペアとマッチング証明書が必要です。 +

+
+
+
+
+

+In a TPM application, both the Attestation private key and the DevID private key MUST be protected by the TPM. Depending on other TPM configuration procedures, the two keys are likely to be different; some of the considerations are outlined in the "TPM 2.0 Keys for Device Identity and Attestation" document [PLATFORM-DEVID-TPM-2.0]. +

+
+
+

+TPMアプリケーションでは、ATSETATIANS秘密キーとDevID秘密鍵の両方がTPMによって保護されなければなりません。他のTPM構成手順に応じて、2つのキーが異なる可能性があります。考慮事項のいくつかは、「デバイスのアイデンティティと証明のためのTPM 2.0キー」ドキュメント[Platform-Devid-TPM-2.0]で概説されています。 +

+
+
+
+
+

+The "TPM 2.0 Keys for Device Identity and Attestation" document [PLATFORM-DEVID-TPM-2.0] specifies further conventions for these keys: +

+
+
+

+「デバイスのアイデンティティと証明のためのTPM 2.0キー」ドキュメント[Platform-Devid-TPM-2.0]は、これらのキーのさらなる規則を指定します。 +

+
+
+
+
+

+* When separate Identity and Attestation keys are used, the AK and its X.509 certificate should parallel the DevID, with the same unique device identification as the DevID certificate (that is, the same subject and subjectAltName (if present), even though the key pairs are different). By examining the corresponding AK certificate, the Verifier can directly link a device's quote, which was signed by an AK, to the device that provided it. If the subject in the AK certificate doesn't match the corresponding DevID certificate, or if they're signed by different authorities, the Verifier may signal the detection of an Asokan-style person-in-the-middle attack (see Section 5.2). +

+
+
+

+* 個別のIDと証明キーを使用する場合、AKとそのX.509証明書は、devid証明書と同じ一意のデバイス識別（つまり、同じサブジェクトとsubjectaltname（存在する場合）である場合でも、devidと並行する必要があります。ペアは異なります）。対応するAK証明書を調べることにより、検証者は、AKによって署名されたデバイスの引用を、提供したデバイスに直接リンクできます。AK証明書の被験者が対応するDevid証明書と一致しない場合、または異なる当局によって署名されている場合、検証者はアソカンスタイルの中間攻撃の検出を信号することができます（セクション5.2を参照）。 +

+
+
+
+
+

+* Network devices that are expected to use SZTP as specified in [RFC8572] MUST be shipped by the manufacturer with pre-provisioned keys (Initial DevID and Initial AK, called IDevID and IAK, respectively). IDevID and IAK certificates MUST both be signed by the Endorser (typically the device manufacturer). Inclusion of an IDevID and IAK by a vendor does not preclude a mechanism whereby an administrator can define LDevID and Local Attestation Keys (LAK) if desired. +

+
+
+

+* [RFC8572]で指定されているSZTPを使用すると予想されるネットワークデバイスは、製造業者が事前に生成されたキー（初期devidおよびIdevidおよびIAKと呼ばれる初期AK）を備えた出荷する必要があります。IDEVIDとIAKの証明書は、両方ともエンドーザー（通常はデバイスメーカー）によって署名されなければなりません。ベンダーによるIDEVIDとIAKを含めることは、管理者が必要に応じてLDEVIDおよびローカル証明キー（LAK）を定義できるメカニズムを排除しません。 +

+
+
+
+
+
+2.3. RIV Information Flow +
+
+
+
+2.3. RIV情報の流れ +
+
+
+
+
+

+RIV workflow for network equipment is organized around a simple use case where a network operator wishes to verify the integrity of software installed in specific, fielded devices. A normative taxonomy of terms is given in [RFC9334], but as a reminder, this use case implies several roles and objects: +

+
+
+

+ネットワーク機器のRIVワークフローは、ネットワークオペレーターが特定のフィールドデバイスにインストールされているソフトウェアの整合性を確認したい単純なユースケースを中心に編成されています。用語の規範的な分類法は[RFC9334]に与えられていますが、リマインダーとして、このユースケースはいくつかの役割とオブジェクトを意味します。 +

+
+
+
+
+

+Attester: +

+
+
+

+アテスター： +

+
+
+
+
+

+The device that the network operator wants to examine. +

+
+
+

+ネットワークオペレーターが調べたいデバイス。 +

+
+
+
+
+

+Verifier: +

+
+
+

+Verifier： +

+
+
+
+
+

+Which might be a Network Management Station and is somewhat separate from the Device that will retrieve the signed evidence and measurement logs, and analyze them to pass judgment on the security posture of the device. +

+
+
+

+これはネットワーク管理ステーションである可能性があり、署名された証拠と測定ログを取得し、デバイスのセキュリティ姿勢に関する判断を渡すためにそれらを分析するデバイスとは多少分離されています。 +

+
+
+
+
+

+Relying Party: +

+
+
+

+頼るパーティー： +

+
+
+
+
+

+Can act on Attestation Results. Interaction between the Relying Party and the Verifier is considered out of scope for RIV. +

+
+
+

+証明の結果に基づいて行動できます。依存者と検証剤の間の相互作用は、RIVの範囲外であると見なされます。 +

+
+
+
+
+

+Signed Reference Integrity Manifests (RIMs): +

+
+
+

+署名された参照整合性マニフェスト（RIMS）： +

+
+
+
+
+

+Contains Reference Values. RIMs can either be created by the device manufacturer and shipped along with the device as part of its software image, or alternatively, could be obtained several other ways (direct to the Verifier from the manufacturer, from a third party, from the owner's concept of a "known good system", etc.). Retrieving RIMs from the device itself allows attestation to be done in systems that may not have access to the public Internet, or by other devices that are not management stations per se (e.g., a peer device; see Section 3.1.3). If Reference Values are obtained from multiple sources, the Verifier may need to evaluate the relative level of trust to be placed in each source in case of a discrepancy. +

+
+
+

+参照値が含まれています。RIMは、デバイスメーカーによって作成され、ソフトウェアイメージの一部としてデバイスとともに出荷することも、他のいくつかの方法を取得することもできます（製造業者から、第三者から、所有者の所有者の概念から、メーカーからの検証者に直接取得できます。「既知の良いシステム」など）。デバイス自体からリムを取得することで、パブリックインターネットにアクセスできないシステムや、管理ステーション自体ではない他のデバイス（例：ピアデバイス、セクション3.1.3を参照）で証明を行うことができます。複数のソースから参照値が取得される場合、検証者は、不一致の場合に各ソースに配置される相対的な信頼レベルを評価する必要がある場合があります。 +

+
+
+
+
+

+These components are illustrated in Figure 2. +

+
+
+

+これらのコンポーネントを図2に示します。 +

+
+
+
+
+ 
+   +----------------+        +-------------+        +---------+--------+
+   |Reference Value |        | Attester    | Step 1 | Verifier|        |
+   |Provider        |        | (Device     |<-------| (Network| Relying|
+   |(Device         |        | under       |------->| Mgmt    | Party  |
+   |Manufacturer    |        | attestation)| Step 2 | Station)|        |
+   |or other        |        |             |        |         |        |
+   |authority)      |        |             |        |         |        |
+   +----------------+        +-------------+        +---------+--------+
+          |                                             /\
+          |                  Step 0                      |
+          -----------------------------------------------
+
+
+
+
+
+

+Figure 2: RIV Reference Configuration for Network Equipment +

+
+
+

+図2：ネットワーク機器のRIV参照構成 +

+
+
+
+
+

+Step 0: The Reference Value Provider (the device manufacturer or other authority) makes one or more RIMs, which correspond to the software image expected to be found on the device and are signed by the Reference Value Provider, available to the Verifier. (See Section 3.1.3 for "in-band" and "out of band" ways to make this happen.) +

+
+
+

+ステップ0：基準値プロバイダー（デバイスメーカーまたはその他の機関）は、デバイスにあると予想されるソフトウェア画像に対応し、検証者が利用できる参照値プロバイダーによって署名されます。（これを実現するための「インバンド」および「バンドから外れ」の方法については、セクション3.1.3を参照してください。） +

+
+
+
+
+

+Step 1: On behalf of a Relying Party, the Verifier (Network Management Station) requests DevID, Measurement Values, and possibly RIMs from the Attester. +

+
+
+

+ステップ1：依存している当事者に代わって、検証者（ネットワーク管理ステーション）は、devid、測定値、および場合によってはアテスターにリムを要求します。 +

+
+
+
+
+

+Step 2: The Attester responds to the request by providing a DevID, quotes (measured values that are signed by the Attester), and optionally RIMs. +

+
+
+

+ステップ2：Attesterは、Devid、引用符（Attesterが署名する測定値）、およびオプションでリムを提供することにより、リクエストに応答します。 +

+
+
+
+
+

+The use of the following standards components allows for interoperability: +

+
+
+

+次の標準コンポーネントを使用すると、相互運用性が可能になります。 +

+
+
+
+
+

+1. TPM keys MUST be configured according to [PLATFORM-DEVID-TPM-2.0] or [PLATFORM-ID-TPM-1.2]. +

+
+
+

+1. TPMキーは、[Platform-Devid-TPM-2.0]または[Platform-ID-TPM-1.2]に従って構成する必要があります。 +

+
+
+
+
+

+2. For devices using UEFI and Linux, measurements of firmware and bootable modules MUST be taken according to "TCG EFI Platform Specification" [PC-CLIENT-EFI-TPM-1.2] or "TCG PC Client Specific Platform Firmware Profile Specification" [PC-CLIENT-BIOS-TPM-2.0], and Linux IMA [IMA]. +

+
+
+

+2. UEFIとLinuxを使用するデバイスの場合、「TCG EFIプラットフォーム仕様」[PC-Client-EFI-TPM-1.2]または「TCG PCクライアント固有のプラットフォームファームウェアプロファイル仕様」に従ってファームウェアと起動可能なモジュールの測定値を取得する必要があります[PC-Client-BIOS-TPM-2.0]、およびLinux IMA [IMA]。 +

+
+
+
+
+

+3. DevID MUST be managed as DevID certificates as specified in IEEE Std 802.1AR [IEEE-802-1AR], with keys protected by TPMs. +

+
+
+

+3. Devidは、TPMSで保護されているキーを使用して、IEEE STD 802.1AR [IEEE-802-1AR]で指定されているDevid証明書として管理する必要があります。 +

+
+
+
+
+

+4. Attestation logs from Linux-based systems MUST be formatted according to the "Canonical Event Log Format" [CEL]. UEFI-based systems MUST use the TCG UEFI BIOS event log [PC-CLIENT-EFI-TPM-1.2] for TPM 1.2 systems and the "TCG PC Client Specific Platform Firmware Profile" [PC-CLIENT-BIOS-TPM-2.0] for TPM 2.0 systems. +

+
+
+

+4. Linuxベースのシステムからの証明ログは、「Canonical Event Log Format」[CEL]に従ってフォーマットする必要があります。UEFIベースのシステムは、TPM 1.2システムと「TCG PCクライアント固有のプラットフォームファームウェアプロファイル」にTCG UEFI BIOSイベントログ[PC-Client-EFI-TPM-1.2]を使用する必要があります[PC-Client-BIOS-TPM-2.0]TPM 2.0システム。 +

+
+
+
+
+

+5. Quotes MUST be retrieved from the TPM according to the TCG Trusted Attestation Protocol Information Model (TAP IM) [TAP] and the Challenge-Response-based Remote Attestation (CHARRA) YANG model [RFC9684]. While the TAP IM gives a protocol-independent description of the data elements involved, it's important to note that quotes from the TPM are signed inside the TPM and MUST be retrieved in a way that does not invalidate the signature, to preserve the trust model. The CHARRA YANG model [RFC9684] is used for this purpose. (See Section 5, Security Considerations). +

+
+
+

+5. 引用は、TCG Trusted Attestation Protocol Information Model（TAP IM）[TAP]およびチャレンジ応答ベースのリモート証明（Charra）Yangモデル[RFC9684]に従ってTPMから取得する必要があります。TAP IMは、関連するデータ要素のプロトコルに依存しない説明を提供しますが、TPMからの引用はTPM内で署名されており、信頼モデルを保存するために署名を無効にしない方法で取得する必要があることに注意することが重要です。この目的には、Charra Yangモデル[RFC9684]が使用されます。（セクション5、セキュリティに関する考慮事項を参照）。 +

+
+
+
+
+

+6. Reference Values MUST be encoded as defined in the TCG RIM document [RIM], typically using Software Identification (SWID) tags [SWID] [NIST-IR-8060] or Concise SWID (CoSWID) tags [RFC9393]. +

+
+
+

+6. 参照値は、TCG RIMドキュメント[RIM]で定義されているようにエンコードする必要があります。通常、ソフトウェア識別（SWID）タグ[SWID] [NIST-IR-8060]または簡潔なSWID（COSWID）タグ[RFC9393]を使用する必要があります。 +

+
+
+
+
+
+2.4. RIV Simplifying Assumptions +
+
+
+
+2.4. RIVの単純化仮定 +
+
+
+
+
+

+This document makes the following simplifying assumptions to reduce complexity: +

+
+
+

+このドキュメントは、複雑さを減らすために次の単純化された仮定を作成します。 +

+
+
+
+
+

+* The product to be attested MUST be shipped by the equipment vendor with both a DevID as specified by IEEE Std 802.1AR and an IAK, with certificates in place. The IAK certificate must contain the same identity information as the DevID (specifically, the same subject and subjectAltName (if used), signed by the manufacturer). The IAK is a type of key that can be used to sign a TPM Quote, but not other objects (i.e., it's marked as a TCG "Restricted" key; this convention is described in "TPM 2.0 Keys for Device Identity and Attestation" [PLATFORM-DEVID-TPM-2.0]). For network equipment, which is generally not privacy sensitive, shipping a device with both an IDevID and an IAK already provisioned substantially simplifies initial startup. +

+
+
+

+* 証明される製品は、IEEE STD 802.1ARで指定されているDevidとIAKの両方を使用して、証明書を設定したDevidを使用して、機器ベンダーが出荷する必要があります。IAK証明書には、Devidと同じID情報を含める必要があります（具体的には、メーカーが署名した同じ件名とsubjectaltname（使用する場合））。IAKは、TPMの見積もりに署名するために使用できるキーの一種ですが、他のオブジェクトではありません（つまり、TCG「制限付き」キーとしてマークされています。この規則は、「デバイスのアイデンティティと証明のためのTPM 2.0キー」で説明されています。Platform-Devid-TPM-2.0]）。一般的にプライバシーに敏感ではないネットワーク機器の場合、IDEVIDとIAKの両方を備えたデバイスにすでにプロビジョニングされているデバイスは、初期スタートアップを大幅に簡素化します。 +

+
+
+
+
+

+* IEEE Std 802.1AR does not require a product serial number as part of the subject, but RIV-compliant devices MUST include their serial numbers in the DevID/IAK certificates to simplify tracking logistics for network equipment users. All other optional 802.1AR fields remain optional in RIV. +

+
+
+

+* IEEE STD 802.1ARは、被験者の一部として製品のシリアル番号を必要としませんが、RIVに準拠したデバイスには、ネットワーク機器ユーザーの追跡ロジスティクスを簡素化するために、DevID/IAK証明書にシリアル番号を含める必要があります。他のすべてのオプションの802.1ARフィールドは、RIVでオプションのままです。 +

+
+
+
+
+

+It should be noted that the use of X.509 certificate fields as specified by IEEE Std 802.1AR is not identical to that described in [RFC9525] for representation of application service identity. +

+
+
+

+IEEE STD 802.1ARで指定されているX.509証明書フィールドの使用は、アプリケーションサービスIDを表現するために[RFC9525]で説明されているものと同一ではないことに注意してください。 +

+
+
+
+
+

+* The product MUST be equipped with an RTM, a Root of Trust for Storage, and a Root of Trust for Reporting (as defined in [SP800-155]), which together are capable of conforming to the TCG TAP IM [TAP]. +

+
+
+

+* この製品には、RTM、ストレージの信頼のルート、およびレポートのための信頼のルート（[SP800-155]で定義されている）を装備する必要があります。 +

+
+
+
+
+

+* The authorized software supplier MUST make available Reference Values in the form of signed SWID or CoSWID tags. +

+
+
+

+* 承認されたソフトウェアサプライヤーは、署名されたSWIDまたはCosWIDタグの形で利用可能な参照値を作成する必要があります。 +

+
+
+
+
+
+2.4.1. Reference Integrity Manifests (RIMs) +
+
+
+
+2.4.1. 参照整合性マニフェスト（リム） +
+
+
+
+
+

+[RFC9684] focuses on collecting and transmitting evidence in the form of PCR measurements and attestation logs. But the critical part of the process is enabling the Verifier to decide whether the measurements are "the right ones" or not. +

+
+
+

+[RFC9684]は、PCR測定と証明ログの形で証拠を収集および送信することに焦点を当てています。しかし、プロセスの重要な部分は、検証者が測定値が「正しいもの」であるかどうかを決定できるようにすることです。 +

+
+
+
+
+

+While it must be up to network administrators to decide what they want on their networks, the software supplier should supply the Reference Values, in signed RIMs, that may be used by a Verifier to determine if evidence shows known good, known bad, or unknown software configurations. +

+
+
+

+ネットワークで何を望んでいるかを決定するのはネットワーク管理者次第でなければなりませんが、ソフトウェアサプライヤーは、証拠が既知の良い、既知の悪い、または未知の証拠が示されるかどうかを判断するために使用される署名されたリムで、参照値を署名したリムで提供する必要があります。ソフトウェア構成。 +

+
+
+
+
+

+In general, there are two kinds of reference measurements: +

+
+
+

+一般的に、参照測定には2種類あります。 +

+
+
+
+
+

+1. Measurements of early system startup (e.g., BIOS, boot loader, OS kernel) are essentially single threaded and executed exactly once, in a known sequence, before any results can be reported. In this case, while the method for computing the hash and extending relevant PCRs may be complicated, the net result is that the software (more likely, firmware) vendor will have one known good PCR value that "should" be present in the relevant PCRs after the box has booted. In this case, the signed reference measurement could simply list the expected hashes for the given version. However, a RIM that contains the intermediate hashes can be useful in debugging cases where the expected final hash is not the one reported. +

+
+
+

+1. 初期のシステムスタートアップの測定（例：BIOS、ブートローダー、OSカーネル）は、結果を報告する前に、既知のシーケンスで本質的に単一のスレッド化および実行されます。この場合、ハッシュを計算して関連するPCRを拡張する方法は複雑な場合がありますが、最終的な結果は、ソフトウェア（より可能性が高い、ファームウェア）ベンダーが、関連するPCRに「」存在する必要がある良いPCR値を持つことになることです。ボックスが起動した後。この場合、署名された参照測定は、指定されたバージョンの予想ハッシュを単純にリストすることができます。ただし、中間のハッシュを含むリムは、予想される最終的なハッシュが報告されていないケースのデバッグに役立ちます。 +

+
+
+
+
+

+2. Measurements taken later in operation of the system, once an OS has started (for example, Linux IMA [IMA]), may be more complex, with unpredictable "final" PCR values. In this case, the Verifier must have enough information to reconstruct the expected PCR values from logs and signed reference measurements from a trusted authority. +

+
+
+

+2. OSが開始されると（Linux IMA [IMA]）、予測不可能な「最終」PCR値がある場合（たとえば、Linux IMA [IMA]）、システムの操作後に取得された測定値がより複雑になる可能性があります。この場合、検証者は、ログから予想されるPCR値を再構築し、信頼できる当局からの署名された参照測定値を再構築するのに十分な情報を持っている必要があります。 +

+
+
+
+
+

+In both cases, the expected values can be expressed as signed SWID or CoSWID tags, but the SWID structure in the second case is somewhat more complex, as reconstruction of the extended hash in a PCR may involve thousands of files and other objects. +

+
+
+

+どちらの場合も、予想される値は署名されたSWIDまたはCosWIDタグとして表現できますが、PCRでの拡張ハッシュの再構築が数千のファイルや他のオブジェクトが関与する可能性があるため、2番目のケースのSWID構造はやや複雑です。 +

+
+
+
+
+

+TCG has published an information model defining elements of RIMs under the title "TCG Reference Integrity Manifest (RIM) Information Model" [RIM]. This information model outlines how SWID tags should be structured to allow attestation, and it defines "bundles" of SWID tags that may be needed to describe a complete software release. The RIM contains metadata relating to the software release it belongs to, plus hashes for each individual file or other object that could be attested. +

+
+
+

+TCGは、「TCG Reference Integrity Manifest（RIM）情報モデル」というタイトルでRIMの要素を定義する情報モデルを公開しています[RIM]。この情報モデルでは、SWIDタグをどのように構成して証明を可能にするかを概説し、完全なソフトウェアリリースを説明するために必要なSWIDタグの「バンドル」を定義します。RIMには、それが属するソフトウェアリリースに関連するメタデータと、証明できる個々のファイルまたは他のオブジェクトのハッシュが含まれています。 +

+
+
+
+
+

+Many network equipment vendors use a UEFI BIOS to launch their network operating system. These vendors may want to also use the "TCG PC Client Reference Integrity Manifest Specification" [PC-CLIENT-RIM], which focuses specifically on a SWID-compatible format suitable for expressing measurement values expected from a UEFI BIOS. +

+
+
+

+多くのネットワーク機器ベンダーは、UEFI BIOSを使用してネットワークオペレーティングシステムを起動しています。これらのベンダーは、UEFI BIOSから予想される測定値を表現するのに適したSWID互換形式に特に焦点を当てた「TCG PCクライアントリファレンスインテグリティマニフェスト仕様」[PC-Client-RIM]を使用することもできます。 +

+
+
+
+
+
+2.4.2. Attestation Logs +
+
+
+
+2.4.2. 証明ログ +
+
+
+
+
+

+Quotes from a TPM can provide evidence of the state of a device up to the time the evidence was recorded. However, to make sense of the quote in cases where several events are extended into one PCR, an event log that identifies which software modules contributed which values to the quote during startup must also be provided. When required, the log MUST contain enough information to demonstrate its integrity by allowing exact reconstruction of the digest conveyed in the signed quote (that is, calculating the hash of all the hashes in the log should produce the same values as contained in the PCRs; if they don't match, the log may have been tampered with. See Appendix A.1). +

+
+
+

+TPMからの引用は、証拠が記録された時まで、デバイスの状態の証拠を提供できます。ただし、いくつかのイベントが1つのPCRに拡張される場合の引用を理解するために、起動中の引用にどのソフトウェアモジュールが寄与したかを識別するイベントログも提供する必要があります。必要に応じて、ログには、署名された引用で伝えられたダイジェストの正確な再構成を許可することにより、その完全性を示すのに十分な情報を含める必要があります（つまり、ログ内のすべてのハッシュのハッシュを計算すると、PCRSに含まれるものと同じ値が生成されるはずです。それらが一致しない場合、ログに改ざんされている可能性があります。 +

+
+
+
+
+

+There are multiple event log formats that may be supported as viable formats of Evidence between the Attester and Verifier; however, to simplify interoperability, RIV focuses on just three: +

+
+
+

+AdtesterとVerifierの間で実行可能な形式の証拠としてサポートされる可能性のある複数のイベントログ形式があります。ただし、相互運用性を簡素化するために、RIVは3つだけに焦点を当てています。 +

+
+
+
+
+

+1. TCG UEFI BIOS event log for TPM 2.0 ("TCG PC Client Specific Platform Firmware Profile Specification") [PC-CLIENT-BIOS-TPM-2.0] +

+
+
+

+1. TPM 2.0のTCG UEFI BIOSイベントログ（ "TCG PCクライアント固有のプラットフォームファームウェアプロファイル仕様"）[PC-Client-BIOS-TPM-2.0] +

+
+
+
+
+

+2. TCG UEFI BIOS event log for TPM 1.2 ("TCG EFI Platform Specification" for TPM Family 1.1 or 1.2, Section 7) [PC-CLIENT-EFI-TPM-1.2] +

+
+
+

+2. TPM 1.2のTCG UEFI BIOSイベントログ（TPMファミリー1.1または1.2、セクション7の「TCG EFIプラットフォーム仕様」）[PC-Client-EFI-TPM-1.2] +

+
+
+
+
+

+3. TCG "Canonical Event Log Format" [CEL] +

+
+
+

+3. TCG "Canonical Event Log Format" [cel] +

+
+
+
+
+
+3. Standards Components +
+
+
+
+3. 標準コンポーネント +
+
+
+
+
+
+3.1. Prerequisites for RIV +
+
+
+
+3.1. RIVの前提条件 +
+
+
+
+
+

+The Reference Interaction Model for Challenge-Response-based Remote Attestation ([RATS-INTERACTION-MODELS]) is based on the standard roles defined in [RFC9334]. However, additional prerequisites have been established to allow for interoperable implementations of RIV use cases. These prerequisites are intended to provide sufficient context information so that the Verifier can acquire and evaluate measurements collected by the Attester. +

+
+
+

+チャレンジ応答ベースのリモート証明（[rats-interaction-models]）の参照相互作用モデルは、[RFC9334]で定義されている標準的な役割に基づいています。ただし、RIVユースケースの相互運用可能な実装を可能にするために、追加の前提条件が確立されています。これらの前提条件は、検証者が攻撃者によって収集された測定値を取得および評価できるように、十分なコンテキスト情報を提供することを目的としています。 +

+
+
+
+
+
+3.1.1. Unique Device Identity +
+
+
+
+3.1.1. ユニークなデバイスアイデンティティ +
+
+
+
+
+

+A DevID in the form of a DevID certificate as specified by IEEE Std 802.1AR [IEEE-802-1AR] must be provisioned in the Attester's TPMs. +

+
+
+

+IEEE STD 802.1AR [IEEE-802-1AR]によって指定されているDevid証明書の形式のDevidは、AttesterのTPMSでプロビジョニングする必要があります。 +

+
+
+
+
+
+3.1.2. Keys +
+
+
+
+3.1.2. キー +
+
+
+
+
+

+The AK and certificate must also be provisioned on the Attester according to [PLATFORM-DEVID-TPM-2.0] or [PLATFORM-ID-TPM-1.2]. +

+
+
+

+AKと証明書は、[Platform-Devid-TPM-2.0]または[Platform-ID-TPM-1.2]に従って、Attesterにプロビジョニングする必要があります。 +

+
+
+
+
+

+It MUST be possible for the Verifier to determine that the Attester's AKs are resident in the same TPM as its DevID keys (see Section 2.2 and Section 5, Security Considerations). +

+
+
+

+Verifierは、AttesterのAKがDevidキーと同じTPMに居住していることを判断することが可能である必要があります（セクション2.2およびセクション5、セキュリティに関する考慮事項を参照）。 +

+
+
+
+
+
+3.1.3. Appraisal Policy for Evidence +
+
+
+
+3.1.3. 証拠に対する評価ポリシー +
+
+
+
+
+

+As noted in Section 2.3, the Verifier may obtain Reference Values from several sources. In addition, administrators may make authorized, site-specific changes (e.g., keys in key databases) that could impact attestation results. As such, there could be conflicts, omissions, or ambiguities between some Reference Values and collected Evidence. +

+
+
+

+セクション2.3で述べたように、検証者はいくつかのソースから参照値を取得する場合があります。さらに、管理者は、認定の結果に影響を与える可能性のあるサイト固有の変更（キーデータベースのキーなど）を作成する場合があります。そのため、いくつかの参照値と収集された証拠の間には、対立、省略、または曖昧さがある可能性があります。 +

+
+
+
+
+

+The Verifier MUST have an Appraisal Policy for Evidence to evaluate the significance of any discrepancies between different reference sources, or between Reference Values and evidence from logs and quotes. While there must be an Appraisal Policy, this document does not specify the format or mechanism to convey the intended policy, nor does RIV specify mechanisms by which the results of applying the policy are communicated to the Relying Party. +

+
+
+

+検証者は、異なる参照ソース間の矛盾の重要性を評価するための証拠のための評価ポリシーを持っている必要があります。評価ポリシーが必要ですが、このドキュメントでは、意図したポリシーを伝えるための形式またはメカニズムを指定しておらず、RIVはポリシーを適用した結果が依存関係者に伝えられるメカニズムを指定しません。 +

+
+
+
+
+
+3.2. Reference Model for Challenge-Response +
+
+
+
+3.2. チャレンジ応答の参照モデル +
+
+
+
+
+

+Once the prerequisites for RIV are met, a Verifier is able to acquire Evidence from an Attester. Figure 3 illustrates a RIV information flow between a Verifier and an Attester, derived from Section 7.1 of [RATS-INTERACTION-MODELS]. In this diagram, each event with its input and output parameters is shown as "Event(input-params)=>(outputs)". The event times shown correspond to the time types described within Appendix A of [RFC9334]: +

+
+
+

+RIVの前提条件が満たされると、検証剤は到達者から証拠を取得することができます。図3は、[rats-interaction-models]のセクション7.1から派生した、検証剤と攻撃者との間のRIV情報の流れを示しています。この図では、入力パラメーターと出力パラメーターを備えた各イベントは、「イベント（入力パラム）=>（出力）」として表示されます。示されているイベント時間は、[RFC9334]の付録Aに記載されている時間型に対応しています。 +

+
+
+
+
+ 
+   .----------.                               .-----------------------.
+   | Attester |                              | Relying Party/Verifier |
+   '----------'                              '------------------------'
+     time(VG)                                                      |
+   generateClaims(attestingEnvironment)                            |
+      | => claims, eventLogs                                       |
+      |                                                            |
+      |                                                        time(NS)
+      | <-- requestAttestation(handle, authSecIDs, claimSelection) |
+      |                                                            |
+    time(EG)                                                       |
+   collectClaims(claims, claimSelection)                           |
+      | => collectedClaims                                         |
+      |                                                            |
+   generateEvidence(handle, authSecIDs, collectedClaims)           |
+      | => evidence                                                |
+      |                                                    time(RG,RA)
+      | evidence, eventLogs -------------------------------------> |
+      |                                                            |
+      |               appraiseEvidence(evidence, eventLogs, refValues)
+      |                                       attestationResult <= |
+      |                                                            |
+      ~                                                            ~
+      |                                                       time(RX)
+
+
+
+
+
+

+Figure 3: IETF Attestation Information Flow +

+
+
+

+図3：IETF証明情報フロー +

+
+
+
+
+

+Step 1 (time(VG)): +

+
+
+

+ステップ1（時間（VG））： +

+
+
+
+
+

+One or more attesting network device PCRs are extended with measurements. RIV provides no direct link between the time at which the event takes place and the time that it's attested, although streaming attestation as described in [RATS-NET-DEV-SUB] could. +

+
+
+

+1つ以上の証明ネットワークデバイスPCRは、測定により拡張されます。RIVは、イベントが行われる時間とそれが証明された時間との間に直接リンクを提供しませんが、[rats-net-dev-sub]に記載されているストリーミングの証明はありません。 +

+
+
+
+
+

+Step 2 (time(NS)): +

+
+
+

+ステップ2（時間（ns））： +

+
+
+
+
+

+The Verifier generates a unique random nonce ("number used once") and makes a request for one or more PCRs from an Attester. For interoperability, this must be accomplished as specified in "A YANG Data Model for Challenge-Response-Based Remote Attestation (CHARRA) Procedures Using Trusted Platform Modules (TPMs)" [RFC9684]. Both TPM 1.2 and TPM 2.0 allow nonces as large as the operative digest size (i.e., 20 or 32 bytes; see [TPM-1.2] Part 2, Section 5.5, and [TPM-2.0] Part 2, Section 10.4.4). +

+
+
+

+検証剤は、一意のランダムなノンセ（「1回使用される」）を生成し、agettersから1つ以上のPCRをリクエストします。相互運用性のために、これは「信頼できるプラットフォームモジュール（TPMS）を使用したチャレンジ応答ベースのリモートアテスト（CHARA）手順のYangデータモデル」[RFC9684]で指定されているように達成する必要があります。TPM 1.2とTPM 2.0の両方が、手術ダイジェストサイズと同じくらい大きいノンセスを許可します（つまり、20または32バイト。[TPM-1.2]パート2、セクション5.5、および[TPM-2.0]パート2、セクション10.4.4を参照）。 +

+
+
+
+
+

+Step 3 (time(EG)): +

+
+
+

+ステップ3（時間（例））： +

+
+
+
+
+

+On the Attester, measured values are retrieved from the Attester's TPM. This requested PCR evidence along with the Verifier's nonce is called a Quote and is signed by the AK associated with the DevID. Quotes are retrieved according to the CHARRA YANG model [RFC9684]. At the same time, the Attester collects log evidence showing the values have been extended into that PCR. Appendix A.1 gives more detail on how this works and includes references to the structure and contents of quotes in TPM documents. +

+
+
+

+Attesterでは、測定値はAttesterのTPMから取得されます。これは、検証者のノンセとともに、PCRの証拠を要求し、引用と呼ばれ、Devidに関連付けられたAKによって署名されます。引用符は、Charra Yangモデル[RFC9684]に従って取得されます。同時に、Attesterは、値がそのPCRに拡張されていることを示すログの証拠を収集します。付録A.1では、これがどのように機能するかについての詳細を示し、TPMドキュメントの引用符の構造と内容への参照を含んでいます。 +

+
+
+
+
+

+Step 4: +

+
+
+

+ステップ4： +

+
+
+
+
+

+The collected Evidence is passed from the Attester to the Verifier. +

+
+
+

+収集された証拠は、アテスターから検証剤に渡されます。 +

+
+
+
+
+

+Step 5 (time(RG,RA)): +

+
+
+

+ステップ5（時間（RG、RA））： +

+
+
+
+
+

+The Verifier reviews the Evidence and takes action as needed. As the interaction between Relying Party and Verifier is out of scope for RIV, this can be described as one step. +

+
+
+

+Verifierは証拠を確認し、必要に応じて行動を起こします。頼る当事者と検証者の間の相互作用はRIVの範囲外であるため、これは1つのステップとして説明できます。 +

+
+
+
+
+

+* If the signature covering TPM Evidence is not correct, the device SHOULD NOT be trusted. +

+
+
+

+* TPMの証拠をカバーする署名が正しくない場合、デバイスを信頼してはなりません。 +

+
+
+
+
+

+* If the nonce in the response doesn't match the Verifier's nonce, the response may be a replay, and the device SHOULD NOT be trusted. +

+
+
+

+* 応答のNonCEが検証者のNonCEと一致しない場合、応答はリプレイである可能性があり、デバイスを信頼してはなりません。 +

+
+
+
+
+

+* If the signed PCR values do not match the set of log entries that have extended a particular PCR, the device SHOULD NOT be trusted. +

+
+
+

+* 署名されたPCR値が特定のPCRを拡張したログエントリのセットと一致しない場合、デバイスは信頼してはなりません。 +

+
+
+
+
+

+* If the log entries that the Verifier considers important do not match known good values, the device SHOULD NOT be trusted. We note that the process of collecting and analyzing the log can be omitted if the value in the relevant PCR is already a known-good value. +

+
+
+

+* Verifierが重要と見なすログエントリが既知の良い値と一致しない場合、デバイスは信頼してはなりません。関連するPCRの値がすでに既知の値である場合、ログを収集および分析するプロセスを省略できることに注意してください。 +

+
+
+
+
+

+* If the set of log entries are not seen as acceptable by the Appraisal Policy for Evidence, the device SHOULD NOT be trusted. +

+
+
+

+* ログエントリのセットが証拠のための評価ポリシーで受け入れられると見なされない場合、デバイスを信頼してはなりません。 +

+
+
+
+
+

+* If time(RG)-time(NS) is greater than the Appraisal Policy for Evidence's threshold for assessing freshness, the Evidence is considered stale and SHOULD NOT be trusted. +

+
+
+

+* Time（RG）-Time（NS）が新鮮さを評価するための証拠のしきい値の評価ポリシーよりも大きい場合、証拠は古く見なされ、信頼されるべきではありません。 +

+
+
+
+
+
+3.2.1. Transport and Encoding +
+
+
+
+3.2.1. 輸送とエンコーディング +
+
+
+
+
+

+Network Management systems may retrieve signed PCR-based Evidence using NETCONF or RESTCONF with [RFC9684]. In either case, implementations must do so using a secure tunnel. +

+
+
+

+ネットワーク管理システムは、[RFC9684]を使用してNetConfまたはRestConfを使用して、署名されたPCRベースの証拠を取得する場合があります。どちらの場合でも、実装は安全なトンネルを使用してそうする必要があります。 +

+
+
+
+
+

+Log Evidence MUST be retrieved via log interfaces specified in [RFC9684]. +

+
+
+

+[RFC9684]で指定されたログインターフェイスを介して、ログ証拠を取得する必要があります。 +

+
+
+
+
+
+3.3. Centralized vs. Peer-to-Peer +
+
+
+
+3.3. 集中型とピアツーピア +
+
+
+
+
+

+Figure 3 assumes that the Verifier is trusted, while the Attester is not. In a peer-to-peer application such as two routers negotiating a trust relationship, the two peers can each ask the other to prove software integrity. In this application, the information flow is the same, but each side plays a role both as an Attester and a Verifier. Each device issues a challenge, and each device responds to the other's challenge, as shown in Figure 4. Peer-to-peer challenges, particularly if used to establish a trust relationship between routers, require devices to carry their own signed reference measurements (RIMs). Devices may also have to carry an appraisal policy for evidence for each possible peer device so that each device has everything needed for remote attestation, without having to resort to a central authority. +

+
+
+

+図3は、検証剤が信頼されていると仮定していますが、攻撃はそうではありません。信頼関係を交渉する2つのルーターなどのピアツーピアアプリケーションでは、2つのピアがそれぞれソフトウェアの完全性を証明するように依頼することができます。このアプリケーションでは、情報の流れは同じですが、それぞれの側は、攻撃者と検証剤の両方として役割を果たします。各デバイスは課題を発行し、図4に示すように、各デバイスは相手の課題に応答します。特にルーター間の信頼関係を確立するために使用される場合、ピアツーピアの課題は、独自の参照測定値を運ぶためにデバイスが必要です（RIMS）。また、デバイスは、各デバイスが中央当局に頼ることなく、リモートの証明に必要なものすべてを持つように、可能な各ピアデバイスの証拠について評価ポリシーを携帯する必要がある場合があります。 +

+
+
+
+
+ 
+   +---------------+                            +---------------+
+   | RefVal        |                            | RefVal        |
+   | Provider A    |                            | Provider B    |
+   | Firmware      |                            | Firmware      |
+   | Configuration |                            | Configuration |
+   | Authority     |                            | Authority     |
+   |               |                            |               |
+   +---------------+                            +---------------+
+         |                                             |
+         |                                             |Step 0B
+         |       +------------+        +------------+  |
+         |       |            | Step 1 |            |  |   \
+         |       | Attester   |<------>| Verifier   |  |   |
+         |       |            |<------>|            |  |   |  Router B
+         +------>|            | Step 2 |            |  |   |- Challenges
+          Step 0A|            |        |            |  |   |  Router A
+                 |            |------->|            |  |   |
+                 |- Router A -| Step 3 |- Router B -|  |   /
+                 |            |        |            |  |
+                 |            |        |            |  |
+                 |            | Step 1 |            |  |   \
+                 | Verifier   |<------>| Attester   |<-+   |  Router A
+                 |            |<------>|            |      |- Challenges
+                 |            | Step 2 |            |      |  Router B
+                 |            |        |            |      |
+                 |            |<-------|            |      |
+                 +------------+ Step 3 +------------+      /
+
+
+
+
+
+

+Figure 4: Peer-to-Peer Attestation Information Flow +

+
+
+

+図4：ピアツーピアの証明情報フロー +

+
+
+
+
+

+In this application, each device may need to be equipped with signed RIMs to act as an Attester, and to allow each device to act as a Verifier, each may need to be equipped with an Appraisal Policy for Evidence and a selection of trusted X.509 root certificates also. An existing link layer protocol such as 802.1X [IEEE-802.1X] or 802.1AE [IEEE-802.1AE], with Evidence being enclosed over a variant of the Extensible Authentication Protocol (EAP) [RFC3748] or Link Layer Discovery Protocol (LLDP) [LLDP], are suitable methods for such an exchange. Details of peer-to-peer operation are out of scope for this document. +

+
+
+

+このアプリケーションでは、各デバイスに登録者として機能し、各デバイスが検証剤として機能するようにするために署名されたリムを装備する必要がある場合があります。509ルート証明書も。802.1x [IEEE-802.1x]または802.1AE [IEEE-802.1AE]などの既存のリンクレイヤープロトコル。拡張可能な認証プロトコル（EAP）[RFC3748]またはリンクレイヤー発見プロトコル（LLDPP）のバリアントに証拠が囲まれています。）[LLDP]、そのような交換に適した方法です。ピアツーピア操作の詳細は、このドキュメントの範囲外です。 +

+
+
+
+
+
+4. Privacy Considerations +
+
+
+
+4. プライバシーに関する考慮事項 +
+
+
+
+
+

+Network equipment, such as routers, switches, and firewalls, has a key role to play in guarding the privacy of individuals using the network. Network equipment generally adheres to several rules to protect privacy: +

+
+
+

+ルーター、スイッチ、ファイアウォールなどのネットワーク機器は、ネットワークを使用して個人のプライバシーを守る上で重要な役割を果たします。ネットワーク機器は一般に、プライバシーを保護するためにいくつかのルールを順守します。 +

+
+
+
+
+

+* Packets passing through the device must not be sent to unauthorized destinations. For example: +

+
+
+

+* デバイスを通過するパケットを不正な宛先に送信しないでください。例えば： +

+
+
+
+
+

+- Routers often act as Policy Enforcement Points, where individual subscribers may be checked for authorization to access a network. Subscriber login information must not be released to unauthorized parties. +

+
+
+

+- 多くの場合、ルーターはポリシー執行ポイントとして機能し、個々のサブスクライバーにネットワークにアクセスする許可を確認できます。サブスクライバーのログイン情報は、不正な当事者にリリースされてはなりません。 +

+
+
+
+
+

+- Network equipment is often called upon to block access to protected resources from unauthorized users. +

+
+
+

+- ネットワーク機器は、許可されていないユーザーから保護されたリソースへのアクセスをブロックするためにしばしば求められています。 +

+
+
+
+
+

+* Routing information, such as the identity of a router's peers, must not be leaked to unauthorized neighbors. +

+
+
+

+* ルーターの仲間の身元などのルーティング情報は、不正な隣人に漏れてはなりません。 +

+
+
+
+
+

+* If configured, encryption and decryption of traffic must be carried out reliably, while protecting keys and credentials. +

+
+
+

+* 構成されている場合、キーと資格情報を保護しながら、トラフィックの暗号化と復号化を確実に実行する必要があります。 +

+
+
+
+
+

+Functions that protect privacy are implemented as part of each layer of hardware and software that makes up the networking device. In light of these requirements for protecting the privacy of users of the network, the network equipment must identify itself, and its boot configuration and measured device state (for example, PCR values), to the equipment's administrator so there's no uncertainty about the device's function and configuration. Attestation is a component that allows the administrator to ensure that the network provides individual and peer privacy guarantees, even though the device itself may not have a right to keep its identity secret. +

+
+
+

+プライバシーを保護する機能は、ネットワークデバイスを構成するハードウェアとソフトウェアの各レイヤーの一部として実装されます。ネットワークのユーザーのプライバシーを保護するためのこれらの要件に照らして、ネットワーク機器はそれ自体とそのブート構成と測定されたデバイス状態（PCR値など）を機器の管理者に識別する必要があるため、デバイスの機能に関する不確実性はありませんおよび構成。証明は、デバイス自体にアイデンティティを秘密にする権利がない場合でも、管理者がネットワークが個人およびピアプライバシーの保証を提供できるようにするコンポーネントです。 +

+
+
+
+
+

+See [NET-EQ] for more context on privacy in networking devices. +

+
+
+

+ネットワーキングデバイスのプライバシーに関するより多くのコンテキストについては、[net-eq]を参照してください。 +

+
+
+
+
+

+While attestation information from network devices is not likely to contain privacy-sensitive content regarding network users, administrators may want to keep attestation records confidential to avoid disclosing versions of software loaded on the device, which is information that could facilitate attacks against known vulnerabilities. +

+
+
+

+ネットワークデバイスからの証明情報には、ネットワークユーザーに関するプライバシーに敏感なコンテンツが含まれている可能性は低いですが、管理者は、既知の脆弱性に対する攻撃を促進できる情報であるデバイスにロードされたソフトウェアのバージョンの開示バージョンを避けるために、機密記録を保持したい場合があります。 +

+
+
+
+
+
+5. Security Considerations +
+
+
+
+5. セキュリティに関する考慮事項 +
+
+
+
+
+

+Specifications such as TLS [RFC8446] and YANG [RFC7950] contain considerable advice on keeping network-connected systems secure. This section outlines specific risks and mitigations related to attestation. +

+
+
+

+TLS [RFC8446]やYang [RFC7950]などの仕様には、ネットワーク接続システムを安全に保つことに関するかなりのアドバイスが含まれています。このセクションでは、認証に関連する特定のリスクと緩和の概要を説明します。 +

+
+
+
+
+

+Attestation Evidence obtained by the RIV procedure is subject to a number of attacks: +

+
+
+

+RIV手順によって得られた証明の証拠は、多くの攻撃の対象となります。 +

+
+
+
+
+

+* Keys may be compromised. +

+
+
+

+* キーが損なわれる可能性があります。 +

+
+
+
+
+

+* A counterfeit device may attempt to impersonate (spoof) a known authentic device. +

+
+
+

+* 偽造デバイスは、既知の本物のデバイスになりすます（スプーフィング）を試みる場合があります。 +

+
+
+
+
+

+* Person-in-the-middle attacks may be used by a compromised device to attempt to deliver responses that originate in an authentic device. +

+
+
+

+* 中間の攻撃は、妥協したデバイスによって使用されて、本物のデバイスに由来する応答を提供しようとすることができます。 +

+
+
+
+
+

+* Replay attacks may be attempted by a compromised device. +

+
+
+

+* リプレイ攻撃は、侵害されたデバイスによって試行される場合があります。 +

+
+
+
+
+
+5.1. Keys Used in RIV +
+
+
+
+5.1. RIVで使用されるキー +
+
+
+
+
+

+Trustworthiness of RIV attestation depends strongly on the validity of keys used for identity and attestation reports. RIV takes full advantage of TPM capabilities to ensure that evidence can be trusted. +

+
+
+

+RIVの証明の信頼性は、アイデンティティと証明レポートに使用されるキーの妥当性に強く依存します。RIVは、TPM機能を最大限に活用して、証拠を信頼できることを確認します。 +

+
+
+
+
+

+Two sets of key pairs are relevant to RIV attestation: +

+
+
+

+2セットのキーペアは、RIVの証明に関連しています。 +

+
+
+
+
+

+* A DevID key pair is used to certify the identity of the device in which the TPM is installed. +

+
+
+

+* DevIDキーペアは、TPMがインストールされているデバイスのIDを認定するために使用されます。 +

+
+
+
+
+

+* An AK key pair is used to certify attestation Evidence (i.e., quotes) and to provide evidence for integrity of the device software. +

+
+
+

+* AKキーペアは、証明の証拠（すなわち、引用）を証明し、デバイスソフトウェアの整合性の証拠を提供するために使用されます。 +

+
+
+
+
+

+TPM practices usually require that these keys be different to ensure that a general-purpose signing key cannot be used to spoof an attestation quote. +

+
+
+

+TPMプラクティスでは、通常、これらのキーが異なることを要求して、一般的な署名キーを使用して証明の見積もりをスプーフィングできないことを確認します。 +

+
+
+
+
+

+In each case, the private half of the key is known only to the TPM and cannot be retrieved externally, even by a trusted party. To ensure that's the case, specification-compliant private/public key pairs are generated inside the TPM, where they are never exposed and cannot be extracted (see [PLATFORM-DEVID-TPM-2.0]). +

+
+
+

+いずれの場合も、キーのプライベートハーフはTPMにのみ知られており、信頼できる当事者であっても外部から取得することはできません。それを確実にするために、仕様に準拠したプライベート/公開キーのペアがTPM内で生成され、そこで露出せず、抽出できません（[プラットフォーム-Devid-TPM-2.0を参照]）。 +

+
+
+
+
+

+Keeping keys safe is a critical enabler of trustworthiness, but it's just part of attestation security; knowing which keys are bound to the device in question is just as important in an environment where private keys are never exposed. +

+
+
+

+キーを安全に保つことは、信頼性の重要なイネーブラーですが、それは証明のセキュリティの一部にすぎません。どのキーが問題のデバイスにバインドされているかを知ることは、プライベートキーが決して露出しない環境でも同様に重要です。 +

+
+
+
+
+

+While there are many ways to manage keys in a TPM (see [PLATFORM-DEVID-TPM-2.0]), RIV includes support for "zero touch" provisioning (also known as zero touch onboarding) of fielded devices (e.g., SZTP [RFC8572]), where keys that have predictable trust properties are provisioned by the device vendor. +

+
+
+

+TPMでキーを管理する方法はたくさんありますが（[プラットフォーム-Devid-TPM-2.0]を参照）、RIVにはフィールドデバイスの「ゼロタッチ」プロビジョニング（ゼロタッチオンボーディングとも呼ばれます）のサポートが含まれています（例えば、SZTP [RFC85722]）、予測可能な信頼プロパティを持つキーがデバイスベンダーによってプロビジョニングされます。 +

+
+
+
+
+

+Device identity in RIV is based on DevID defined by IEEE Std 802.1AR. This specification provides several elements: +

+
+
+

+RIVのデバイスアイデンティティは、IEEE STD 802.1ARによって定義されたDevidに基づいています。この仕様はいくつかの要素を提供します。 +

+
+
+
+
+

+* A DevID requires a unique key pair for each device, accompanied by an X.509 certificate. +

+
+
+

+* devidには、x.509証明書を添付するデバイスごとに一意のキーペアが必要です。 +

+
+
+
+
+

+* The private portion of the DevID key is to be stored in the device, in a manner that provides confidentiality (Section 6.2.5 of [IEEE-802-1AR]). +

+
+
+

+* Devidキーの私的部分は、機密性を提供する方法でデバイスに保存されます（[IEEE-802-1AR]のセクション6.2.5）。 +

+
+
+
+
+

+The X.509 certificate contains several components: +

+
+
+

+X.509証明書にはいくつかのコンポーネントが含まれています。 +

+
+
+
+
+

+* The public part of the unique DevID key assigned to that device allows a challenge of identity. +

+
+
+

+* そのデバイスに割り当てられた一意のdevidキーの公開部分は、アイデンティティの課題を可能にします。 +

+
+
+
+
+

+* An identifying string that's unique to the manufacturer of the device. This is normally the serial number of the unit, which might also be printed on a label on the device. +

+
+
+

+* デバイスのメーカーに固有の識別文字列。これは通常、ユニットのシリアル番号であり、デバイス上のラベルにも印刷される場合があります。 +

+
+
+
+
+

+* The certificate must be signed by a key traceable to the manufacturer's root key. +

+
+
+

+* 証明書は、メーカーのルートキーに追跡可能なキーによって署名する必要があります。 +

+
+
+
+
+

+With these elements, the device's manufacturer and serial number can be identified by analyzing the DevID certificate plus the chain of intermediate certificates leading back to the manufacturer's root certificate. As is conventional in TLS or SSH connections, a random nonce must be signed by the device in response to a challenge, proving possession of its DevID private key. +

+
+
+

+これらの要素を使用すると、デバイスのメーカーとシリアル番号は、DevID証明書に加えて、メーカーのルート証明書に戻る中間証明書のチェーンを分析することで識別できます。TLSまたはSSH接続では従来のように、課題に応じてデバイスによってランダムなノンセに署名する必要があり、DevID秘密キーの所有を証明する必要があります。 +

+
+
+
+
+

+RIV uses the DevID to validate a TLS or SSH connection to the device as the attestation session begins. Security of this process derives from TLS or SSH security, with the DevID, which contains a device serial number, providing proof that the session terminates on the intended device. See [RFC8446] [RFC4253]. +

+
+
+

+RIVは、Devidを使用して、証明セッションが開始されるときにTLSまたはSSH接続をデバイスに検証します。このプロセスのセキュリティは、デバイスのシリアル番号を含むDevidを使用して、TLSまたはSSHセキュリティから派生し、セッションが意図したデバイスで終了することを証明します。[RFC8446] [RFC4253]を参照してください。 +

+
+
+
+
+

+Evidence of software integrity is delivered in the form of a quote that is signed by the TPM itself and accompanied by an IAK certificate containing the same identity information as the DevID. Because the contents of the quote are signed inside the TPM, any external modification (including reformatting to a different data format) after measurements have been taken will be detected as tampering. An unbroken chain of trust is essential for ensuring that blocks of code that are taking measurements have been verified before execution (see Figure 1). +

+
+
+

+ソフトウェアの整合性の証拠は、TPM自体によって署名され、DevIDと同じID情報を含むIAK証明書が添付されている引用の形で配信されます。見積もりの内容はTPM内で署名されているため、測定が行われた後、外部変更（異なるデータ形式への再フォーマットを含む）が改ざんされたものとして検出されます。壊れていない信頼の連鎖は、測定を行っているコードブロックが実行前に検証されていることを確認するために不可欠です（図1を参照）。 +

+
+
+
+
+

+Requiring measurements of the operating software to be signed by a key known only to the TPM also removes the need to trust the device's operating software (beyond the first measurement in the RTM; see below). If malicious software makes any changes to a quote in the device itself, or in the path back to the Verifier, the signature on the quote will be invalidated. +

+
+
+

+TPMにのみ既知のキーによって署名されるようにオペレーティングソフトウェアの測定が必要になると、デバイスのオペレーティングソフトウェアを信頼する必要性も削除されます（RTMの最初の測定を超えて、以下を参照）。悪意のあるソフトウェアがデバイス自体の見積もり、または検証器に戻るパスに変更を加えた場合、引用符の署名は無効になります。 +

+
+
+
+
+

+A critical feature of the YANG model described in [RFC9684] is the ability to carry TPM data structures in their TCG-defined format, without requiring any changes to the structures as they were signed and delivered by the TPM. While alternate methods of conveying TPM quotes could reduce redundant information, or add another layer of signing using external keys, the implementation MUST preserve the TPM signing so that tampering anywhere in the path between the TPM itself and the Verifier can be detected. +

+
+
+

+[RFC9684]で説明されているYangモデルの重要な特徴は、TPMが署名および配信された構造に変更を必要とせずに、TCG定義形式でTPMデータ構造を運ぶ機能です。TPMの引用符を伝える代替方法は、冗長な情報を減らすか、外部キーを使用して署名の別のレイヤーを追加する可能性がありますが、実装はTPM自体と検証者の間のパスのどこにでも改ざんするようにTPMの署名を保持する必要があります。 +

+
+
+
+
+
+5.2. Prevention of Spoofing and Person-in-the-Middle Attacks +
+
+
+
+5.2. スプーフィングと中間者攻撃の防止 +
+
+
+
+
+

+Prevention of spoofing attacks against attestation systems is also important. There are several cases to consider: +

+
+
+

+認証システムに対するスプーフィング攻撃の防止も重要です。考慮すべきいくつかのケースがあります： +

+
+
+
+
+

+* The entire device could be spoofed. If the Verifier goes to appraise a specific Attester, it might be redirected to a different Attester. +

+
+
+

+* デバイス全体をスプーフィングできます。検証者が特定の攻撃を評価する場合、別の攻撃にリダイレクトされる可能性があります。 +

+
+
+
+
+

+* A compromised device could have a valid DevID, but substitute a quote from a known-good device instead of returning its own, as described in [RFC6813]. +

+
+
+

+* 侵害されたデバイスには有効な開発がありますが、[RFC6813]に記載されているように、独自のものを返す代わりに、既知の優れたデバイスからの引用を代用します。 +

+
+
+
+
+

+* A device with a compromised OS could return a fabricated quote providing spoofed attestation Evidence. +

+
+
+

+* OSが侵害されたデバイスは、スプーフィングされた証拠の証拠を提供する製造された引用を返す可能性があります。 +

+
+
+
+
+

+Use of the 802.1AR DevID in the TPM provides protection against the case of a spoofed device by ensuring that the Verifier's TLS or SSH session is in fact terminating on the right device. +

+
+
+

+TPMで802.1AR Devidを使用すると、検証者のTLSまたはSSHセッションが実際に適切なデバイスで終了していることを確認することにより、スプーフィングされたデバイスの場合に対する保護を提供します。 +

+
+
+
+
+

+Protection against spoofed quotes from a device with valid identity is a bit more complex. An identity key must be available to sign any kind of nonce or hash offered by the Verifier, and consequently, could be used to sign a fabricated quote. To block a spoofed Attestation Result, the quote generated inside the TPM must be signed by a key, known as an AK, that's different from the DevID. +

+
+
+

+有効なアイデンティティを持つデバイスからのスプーフィングされた引用に対する保護は、もう少し複雑です。Verifierが提供するあらゆる種類のNONCEまたはハッシュに署名するためにIDキーを使用できる必要があります。その結果、製造された見積に署名するために使用できます。スプーフィングされた証明の結果をブロックするには、TPM内で生成された引用は、Devidとは異なるAKとして知られるキーによって署名する必要があります。 +

+
+
+
+
+

+Given separate Attestation and DevID keys, the binding between the AK and the same device must also be proven to prevent a person-in-the-middle attack (e.g., the "Asokan Attack" [RFC6813]). +

+
+
+

+個別の証明とDevidキーを考えると、AKと同じデバイスの間の結合も、中間の攻撃を防ぐために証明する必要があります（例：「Asokan Attack」[RFC6813]）。 +

+
+
+
+
+

+This is accomplished in RIV through use of an AK certificate with the same elements as the DevID (same manufacturer's serial number and signed by the same manufacturer's key), but containing the device's unique AK public key instead of the DevID public key. This binding between DevID and AK certificates is critical to reliable attestation. +

+
+
+

+これは、Devidと同じ要素を持つAK証明書を使用してRIVで達成されます（同じメーカーのシリアル番号と同じメーカーのキーで署名）が、Devid公開キーの代わりにデバイスのユニークなAK公開キーが含まれています。DevIDとAK証明書の間のこの拘束力は、信頼できる証明にとって重要です。 +

+
+
+
+
+

+The TCG document "TPM 2.0 Keys for Device Identity and Attestation" [PLATFORM-DEVID-TPM-2.0] specifies OIDs for Attestation Certificates that allow the CA to mark a key as specifically known to be an AK. +

+
+
+

+TCGドキュメント「TPM 2.0デバイスのアイデンティティと証明のためのキー」[Platform-Devid-TPM-2.0]は、CAがAKであることが特別に知られているようにキーをマークすることを認める証明書のOIDを指定します。 +

+
+
+
+
+

+These two key pairs and certificates are used together: +

+
+
+

+これらの2つの重要なペアと証明書は一緒に使用されます。 +

+
+
+
+
+

+* The DevID is used to validate a TLS connection terminating on the device with a known serial number. +

+
+
+

+* DevIDは、既知のシリアル番号を使用してデバイス上で終了するTLS接続を検証するために使用されます。 +

+
+
+
+
+

+* The AK is used to sign attestation quotes, which provides proof that the attestation evidence comes from the same device. +

+
+
+

+* AKは、証明の証拠が同じデバイスから得られることの証拠を提供する証明の引用に署名するために使用されます。 +

+
+
+
+
+
+5.3. Replay Attacks +
+
+
+
+5.3. リプレイ攻撃 +
+
+
+
+
+

+Replay attacks, where the results of a previous attestation are submitted in response to subsequent requests, are usually prevented by the inclusion of a random nonce in the request to the TPM for a quote. Each request from the Verifier includes a new random number (a nonce). The resulting quote signed by the TPM contains the same nonce, which allows the Verifier to determine freshness (i.e., that the resulting quote was generated in response to the Verifier's specific request). "Time-Based Uni-Directional Attestation" [RATS-TUDA] provides an alternate mechanism to verify freshness without requiring a request/response cycle. +

+
+
+

+以前の証明の結果がその後のリクエストに応じて提出されるリプレイ攻撃は、通常、見積もりのためにTPMへの要求にランダムな非CEを含めることにより防止されます。検証器からの各要求には、新しい乱数（nonce）が含まれます。TPMによって署名された結果の引用には、同じノンセが含まれているため、検証者は新鮮さを決定できます（つまり、結果の引用が検証剤の特定の要求に応じて生成されたことです）。「時間ベースの一方向の証明」[RATS-TUDA]は、要求/応答サイクルを必要とせずに鮮度を検証する代替メカニズムを提供します。 +

+
+
+
+
+
+5.4. Owner-Signed Keys +
+
+
+
+5.4. 所有者に署名したキー +
+
+
+
+
+

+Although device manufacturers must pre-provision devices with easily verified DevID and AK certificates if SZTP such as described in [RFC8572] is to be supported, use of those credentials is not mandatory. IEEE Std 802.1AR incorporates the idea of an IDevID, which is provisioned by the manufacturer, and a LDevID, which is provisioned by the owner of the device. RIV and [PLATFORM-DEVID-TPM-2.0] extend that concept by defining an IAK and LAK with the same properties. +

+
+
+

+[RFC8572]に記載されているようなSZTPがサポートされる場合、デバイスメーカーは簡単に検証されたDevidおよびAK証明書を使用して、簡単に検証されたDevidおよびAK証明書を使用する必要がありますが、これらの資格情報の使用は必須ではありません。IEEE STD 802.1ARには、メーカーによってプロビジョニングされたIDEVIDのアイデアと、デバイスの所有者によってプロビジョニングされているLDEVIDのアイデアが組み込まれています。RIVと[Platform-Devid-TPM-2.0]は、同じプロパティでIAKとLAKを定義することにより、その概念を拡張します。 +

+
+
+
+
+

+Device owners can use any method to provision the local credentials. +

+
+
+

+デバイスの所有者は、任意の方法を使用してローカル資格情報をプロビジョニングできます。 +

+
+
+
+
+

+* The TCG document [PLATFORM-DEVID-TPM-2.0] shows how the IAKs can be used to certify LDevID and LAK keys. The use of the LDevID and LAK allows the device owner to use a uniform identity structure across device types from multiple manufacturers (in the same way that an "Asset Tag" is used by many enterprises to identify devices they own). The TCG document [PROV-TPM-2.0] also contains guidance on provisioning local identity keys in TPM 2.0. Owners should follow the same practice of binding LDevID and LAK as the manufacturer would for IDevID and IAK. See Section 2.2. +

+
+
+

+* TCGドキュメント[Platform-Devid-TPM-2.0]は、IAKを使用してLDEVIDおよびLAKキーを証明する方法を示しています。LDEVIDとLAKを使用すると、デバイスの所有者は、複数のメーカーのデバイスタイプ全体で均一なアイデンティティ構造を使用できます（多くの企業が所有するデバイスを特定するために「アセットタグ」が使用されるのと同じ方法で）。TCGドキュメント[Prov-TPM-2.0]には、TPM 2.0のローカルIDキーのプロビジョニングに関するガイダンスも含まれています。所有者は、メーカーがIDEVIDとIAKの場合と同じLDEVIDとLAKを拘束するのと同じ慣行に従う必要があります。セクション2.2を参照してください。 +

+
+
+
+
+

+* Device owners, however, can use any other mechanism they want, including physical inspection and programming in a secure location, to assure themselves that local identity certificates are inserted into the intended device if they prefer to avoid placing trust in the manufacturer-provided keys. +

+
+
+

+* ただし、デバイスの所有者は、安全な場所での物理的検査やプログラミングなど、他のメカニズムを使用して、メーカーが提供するキーに信頼を置かないようにすることを好む場合、ローカルID証明書が意図したデバイスに挿入されることを保証することができます。 +

+
+
+
+
+

+Clearly, local keys can't be used for SZTP; installation of the local keys can only be done by some process that runs before the device is installed for network operation, or by using procedures such as those outlined in Bootstrapping Remote Secure Key Infrastructure (BRSKI) [RFC8995]. +

+
+
+

+明らかに、ローカルキーはSZTPには使用できません。ローカルキーのインストールは、ネットワーク操作のためにデバイスがインストールされる前に実行されるプロセス、またはリモートセキュアなキーインフラストラクチャ（BRSKI）[RFC8995]で概説されている手順などの手順を使用することによってのみ実行できます。 +

+
+
+
+
+

+On the other end of the device lifecycle, provision should be made to wipe local keys when a device is decommissioned to indicate that the device is no longer owned by the enterprise. The manufacturer's initial identity keys must be preserved, as they contain no information that's not already printed on the device's serial number plate. +

+
+
+

+デバイスライフサイクルのもう一方の端では、デバイスが廃止されている場合は、デバイスがエンタープライズによって所有されなくなったことを示すためにローカルキーを拭くために提供する必要があります。メーカーの最初のIDキーは、デバイスのシリアルナンバープレートにまだ印刷されていない情報が含まれていないため、保存する必要があります。 +

+
+
+
+
+
+5.5. Other Factors for Trustworthy Operation +
+
+
+
+5.5. 信頼できる操作のためのその他の要因 +
+
+
+
+
+

+In addition to the trustworthy provisioning of keys, RIV depends on a number of other factors for trustworthy operation. +

+
+
+

+キーの信頼できるプロビジョニングに加えて、RIVは信頼できる操作のための他の多くの要因に依存します。 +

+
+
+
+
+

+* Secure identity depends on mechanisms to prevent per-device secret keys from being compromised. The TPM provides this capability as a Root of Trust for Storage. +

+
+
+

+* 安全なアイデンティティは、デバイスごとの秘密キーが侵害されないようにするメカニズムに依存します。TPMは、ストレージの信頼のルートとしてこの機能を提供します。 +

+
+
+
+
+

+* Attestation depends on an unbroken chain of measurements, starting from the very first measurement. See Appendix A.1 for background on TPM practices. +

+
+
+

+* 証明は、最初の測定から始まる壊れていない一連の測定に依存します。TPMプラクティスの背景については、付録A.1を参照してください。 +

+
+
+
+
+

+* That first measurement is made by code called the RTM, typically done by trusted firmware stored in boot flash. Mechanisms for maintaining the trustworthiness of the RTM are out of scope for RIV, but could include immutable firmware, signed updates, or a vendor-specific hardware verification technique. See Appendix A.2 for background on Roots of Trust. +

+
+
+

+* その最初の測定は、通常、ブートフラッシュに保存されている信頼できるファームウェアによって行われるRTMと呼ばれるコードによって行われます。RTMの信頼性を維持するためのメカニズムは、RIVの範囲外ですが、不変のファームウェア、署名された更新、またはベンダー固有のハードウェア検証手法を含めることができます。Roots of Trustの背景については、付録A.2を参照してください。 +

+
+
+
+
+

+* The device owner SHOULD provide some level of physical defense for the device. If a TPM that has already been programmed with an authentic DevID is stolen and is inserted into a counterfeit device, attestation of that counterfeit device may become indistinguishable from an authentic device. +

+
+
+

+* デバイスの所有者は、デバイスにある程度の物理的防御を提供する必要があります。すでに本物のDevidでプログラムされているTPMが盗まれ、偽造デバイスに挿入されている場合、その偽造デバイスの証明は、本物のデバイスと区別できない場合があります。 +

+
+
+
+
+

+RIV also depends on reliable Reference Values, as expressed by the RIM [RIM]. The definition of trust procedures for RIMs is out of scope for RIV, and the device owner is free to use any policy to validate a set of reference measurements. It should also be noted that, while RIV can provide a reliable indication that a known software package is in use by the device and that the package has not been tampered with, it is the device owner's responsibility to determine that it's the correct package for the application. +

+
+
+

+RIVは、RIM [RIM]で表されるように、信頼できる参照値にも依存します。RIMSの信頼手順の定義はRIVの範囲外であり、デバイスの所有者は、あらゆるポリシーを使用して一連の参照測定値を検証できます。また、RIVは、既知のソフトウェアパッケージがデバイスによって使用されていること、およびパッケージが改ざんされていないという信頼できる兆候を提供できるが、それがそれが正しいパッケージであると判断することはデバイスの所有者の責任であることに注意する必要がありますが、それは注意する必要があります。応用。 +

+
+
+
+
+

+RIMs may be conveyed either out-of-band or in-band as part of the attestation process (see Section 3.1.3). However, for network devices, where software is usually shipped as a self-contained package, RIMs signed by the manufacturer and delivered in-band may be more convenient for the device owner. +

+
+
+

+リムは、証明プロセスの一部として、帯域外または帯域内のいずれかを伝えることができます（セクション3.1.3を参照）。ただし、通常、ソフトウェアが自己完結型パッケージとして出荷されるネットワークデバイスの場合、メーカーが署名し、インバンド内で配信されるリムは、デバイスの所有者にとってより便利な場合があります。 +

+
+
+
+
+

+The validity of RIV attestation results is also influenced by procedures used to create Reference Values: +

+
+
+

+RIVの認証結果の妥当性は、参照値を作成するために使用される手順の影響も受けます。 +

+
+
+
+
+

+* While the RIM itself is signed, supply chains SHOULD be carefully scrutinized to ensure that the values are not subject to unexpected manipulation prior to signing. Insider attacks against code bases and build chains are particularly hard to spot. +

+
+
+

+* リム自体に署名されている間、サプライチェーンは、署名前に値が予期しない操作の対象ではないことを確認するために慎重に精査する必要があります。コードベースとビルドチェーンに対するインサイダー攻撃を見つけるのは特に困難です。 +

+
+
+
+
+

+* Designers SHOULD guard against hash collision attacks. RIMs often give hashes for large objects of indeterminate size. If one of the measured objects can be replaced with an implant engineered to produce the same hash, RIV will be unable to detect the substitution. TPM 1.2 only uses SHA-1 hashes, which have been shown to be susceptible to collision attack. TPM 2.0 will produce quotes with SHA-256, which so far has resisted such attacks. Consequently, RIV implementations SHOULD use TPM 2.0. +

+
+
+

+* デザイナーは、ハッシュ衝突攻撃を防ぐ必要があります。リムは、しばしば不定サイズの大きなオブジェクトにハッシュを与えます。測定されたオブジェクトの1つを、同じハッシュを生成するように設計されたインプラントに置き換えることができる場合、RIVは置換を検出できません。TPM 1.2は、衝突攻撃の影響を受けやすいことが示されているSHA-1ハッシュのみを使用します。TPM 2.0は、SHA-256で引用符を作成します。これは、これまでこのような攻撃に抵抗しています。したがって、RIVの実装はTPM 2.0を使用する必要があります。 +

+
+
+
+
+
+6. IANA Considerations +
+
+
+
+6. IANAの考慮事項 +
+
+
+
+
+

+This document has no IANA actions. +

+
+
+

+このドキュメントにはIANAアクションがありません。 +

+
+
+
+
+
+7. Conclusion +
+
+
+
+7. 結論 +
+
+
+
+
+

+TCG technologies can play an important part in the implementation of RIV. Standards for many of the components needed for implementation of RIV already exist: +

+
+
+

+TCGテクノロジーは、RIVの実装において重要な役割を果たすことができます。RIVの実装に必要な多くのコンポーネントの標準はすでに存在しています。 +

+
+
+
+
+

+* Platform identity can be based on IEEE 802.1AR DevID, coupled with careful supply-chain management by the manufacturer. +

+
+
+

+* プラットフォームのアイデンティティは、IEEE 802.1AR Devidに基づいて、メーカーによる慎重な供給鎖管理と組み合わせています。 +

+
+
+
+
+

+* Complex supply chains can be certified using TCG Platform Certificates [PLATFORM-CERTS]. +

+
+
+

+* 複雑なサプライチェーンは、TCGプラットフォーム証明書[Platform-Certs]を使用して認定できます。 +

+
+
+
+
+

+* The TCG TAP mechanism coupled with [RFC9684] can be used to retrieve attestation evidence. +

+
+
+

+* [RFC9684]と組み合わせたTCG TAPメカニズムを使用して、証拠の証拠を取得できます。 +

+
+
+
+
+

+* Reference Values must be conveyed from the software authority (e.g., the manufacturer) in RIMs to the system in which verification will take place. IETF and TCG SWID and CoSWID work ([RFC9393] [RIM]) forms the basis for this function. +

+
+
+

+* 参照値は、RIMSのソフトウェア機関（メーカーなど）から、検証が行われるシステムに伝えられる必要があります。IETFおよびTCG SWIDおよびCOSWIDワーク（[RFC9393] [RIM]）は、この関数の基礎を形成します。 +

+
+
+
+
+
+8. References +
+
+
+
+8. 参考文献 +
+
+
+
+
+
+8.1. Normative References +
+
+
+
+8.1. 引用文献 +
+
+
+
+
+ 
+   [CEL]      Trusted Computing Group, "Canonical Event Log Format",
+              Version 1.0, Revision 0.41, February 2022,
+              <https://trustedcomputinggroup.org/wp-content/uploads/
+              TCG_IWG_CEL_v1_r0p41_pub.pdf>.
+
+
+
+
+
+ 
+   [IEEE-802-1AR]
+              IEEE, "IEEE Standard for Local and Metropolitan Area
+              Networks - Secure Device Identity", IEEE Std 802.1AR-2018,
+              DOI 10.1109/IEEESTD.2018.8423794, August 2018,
+              <https://doi.org/10.1109/IEEESTD.2018.8423794>.
+
+
+
+
+
+ 
+   [IMA]      The kernel development community, "dm-ima", Linux Kernel
+              6.11, 15 September 2024,
+              <https://www.kernel.org/doc/html/v6.11/admin-guide/device-
+              mapper/dm-ima.html>.  The latest version can be found at
+              https://docs.kernel.org/admin-guide/device-mapper/dm-
+              ima.html.
+
+
+
+
+
+ 
+   [PC-CLIENT-BIOS-TPM-2.0]
+              Trusted Computing Group, "TCG PC Client Specific Platform
+              Firmware Profile Specification", Family "2.0", Level 00,
+              Version 1.05, Revision 23, May 2021,
+              <https://trustedcomputinggroup.org/resource/pc-client-
+              specific-platform-firmware-profile-specification/>.
+
+
+
+
+
+ 
+   [PC-CLIENT-EFI-TPM-1.2]
+              Trusted Computing Group, "TCG EFI Platform Specification",
+              For TPM Family 1.1 or 1.2, Version 1.22, Revision 15,
+              January 2014, <https://trustedcomputinggroup.org/resource/
+              tcg-efi-platform-specification/>.
+
+
+
+
+
+ 
+   [PC-CLIENT-RIM]
+              Trusted Computing Group, "TCG PC Client Reference
+              Integrity Manifest Specification", Version 1.04, November
+              2020, <https://trustedcomputinggroup.org/resource/tcg-pc-
+              client-reference-integrity-manifest-specification/>.
+
+
+
+
+
+ 
+   [PLATFORM-DEVID-TPM-2.0]
+              Trusted Computing Group, "TPM 2.0 Keys for Device Identity
+              and Attestation", Version 1.00, Revision 12, October 2021,
+              <https://trustedcomputinggroup.org/resource/tpm-2-0-keys-
+              for-device-identity-and-attestation/>.
+
+
+
+
+
+ 
+   [PLATFORM-ID-TPM-1.2]
+              Trusted Computing Group, "TCG Infrastructure WG TPM Keys
+              for Platform Identity for TPM 1.2", Specification Version
+              1.0, Revision 3, August 2015,
+              <https://trustedcomputinggroup.org/resource/tpm-keys-for-
+              platform-identity-for-tpm-1-2-2/>.
+
+
+
+
+
+ 
+   [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>.
+
+
+
+
+
+ 
+   [RFC4253]  Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
+              Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
+              January 2006, <https://www.rfc-editor.org/info/rfc4253>.
+
+
+
+
+
+ 
+   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+              Housley, R., and W. Polk, "Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
+              <https://www.rfc-editor.org/info/rfc5280>.
+
+
+
+
+
+ 
+   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
+              and A. Bierman, Ed., "Network Configuration Protocol
+              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
+              <https://www.rfc-editor.org/info/rfc6241>.
+
+
+
+
+
+ 
+   [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>.
+
+
+
+
+
+ 
+   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
+              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
+              <https://www.rfc-editor.org/info/rfc8446>.
+
+
+
+
+
+ 
+   [RFC9334]  Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
+              W. Pan, "Remote ATtestation procedureS (RATS)
+              Architecture", RFC 9334, DOI 10.17487/RFC9334, January
+              2023, <https://www.rfc-editor.org/info/rfc9334>.
+
+
+
+
+
+ 
+   [RFC9393]  Birkholz, H., Fitzgerald-McKay, J., Schmidt, C., and D.
+              Waltermire, "Concise Software Identification Tags",
+              RFC 9393, DOI 10.17487/RFC9393, June 2023,
+              <https://www.rfc-editor.org/info/rfc9393>.
+
+
+
+
+
+ 
+   [RFC9684]  Birkholz, H., Eckel, M., Bhandari, S., Voit, E., Sulzen,
+              B., Xia, L., Laffey, T., and G. C. Fedorkow, "A YANG Data
+              Model for Challenge-Response-Based Remote Attestation
+              (CHARRA) Procedures Using Trusted Platform Modules
+              (TPMs)", RFC 9684, DOI 10.17487/RFC9684, December 2024,
+              <https://www.rfc-editor.org/info/rfc9684>.
+
+
+
+
+
+ 
+   [RIM]      Trusted Computing Group, "TCG Reference Integrity Manifest
+              (RIM) Information Model", Version 1.01, Revision 0.16,
+              November 2020,
+              <https://trustedcomputinggroup.org/resource/tcg-reference-
+              integrity-manifest-rim-information-model/>.
+
+
+
+
+
+ 
+   [SWID]     ISO/IEC, "Information technology - IT asset management -
+              Part 2: Software identification tag", ISO/
+              IEC 19770-2:2015, October 2015,
+              <https://www.iso.org/standard/65666.html>.
+
+
+
+
+
+ 
+   [TAP]      Trusted Computing Group, "TCG Trusted Attestation Protocol
+              (TAP) Information Model for TPM Families 1.2 and 2.0 and
+              DICE Family 1.0", Version 1.0, Revision 0.36, October
+              2018, <https://trustedcomputinggroup.org/wp-
+              content/uploads/
+              TNC_TAP_Information_Model_v1.00_r0.36-FINAL.pdf>.
+
+
+
+
+
+
+8.2. Informative References +
+
+
+
+8.2. 参考引用 +
+
+
+
+
+ 
+   [AIK-ENROLL]
+              Trusted Computing Group, "TCG Infrastructure Working Group
+              A CMC Profile for AIK Certificate Enrollment", Version
+              1.0, Revision 7, March 2011,
+              <https://trustedcomputinggroup.org/resource/tcg-
+              infrastructure-working-group-a-cmc-profile-for-aik-
+              certificate-enrollment/>.
+
+
+
+
+
+ 
+   [IEEE-802.1AE]
+              IEEE, "IEEE Standard for Local and metropolitan area
+              networks - Media Access Control (MAC) Security", IEEE Std 
+              802.1AE-2018, DOI 10.1109/IEEESTD.2018.8585421, 2018,
+              <https://doi.org/10.1109/IEEESTD.2018.8585421>.
+
+
+
+
+
+ 
+   [IEEE-802.1X]
+              IEEE, "IEEE Standard for Local and Metropolitan Area
+              Networks - Port-Based Network Access Control", IEEE Std 
+              802.1X-2020, DOI 10.1109/IEEESTD.2020.9018454, February
+              2020, <https://doi.org/10.1109/IEEESTD.2020.9018454>.
+
+
+
+
+
+ 
+   [LLDP]     IEEE, "IEEE Standard for Local and metropolitan area
+              networks - Station and Media Access Control Connectivity
+              Discovery", IEEE Std 802.1AB-2016,
+              DOI 10.1109/IEEESTD.2016.7433915, March 2016,
+              <https://doi.org/10.1109/IEEESTD.2016.7433915>.
+
+
+
+
+
+ 
+   [NET-EQ]   Trusted Computing Group, "TCG Guidance for Securing
+              Network Equipment Using TCG Technology", Version 1.0,
+              Revision 29, January 2018,
+              <https://trustedcomputinggroup.org/resource/tcg-guidance-
+              securing-network-equipment/>.
+
+
+
+
+
+ 
+   [NIST-IR-8060]
+              Waltermire, D., Cheikes, B. A., Feldman, L., and G. Witte,
+              "Guidelines for the Creation of Interoperable Software
+              Identification (SWID) Tags", NIST NISTIR 8060,
+              DOI 10.6028/NIST.IR.8060, April 2016,
+              <https://nvlpubs.nist.gov/nistpubs/ir/2016/
+              NIST.IR.8060.pdf>.
+
+
+
+
+
+ 
+   [PLATFORM-CERTS]
+              Trusted Computing Group, "TCG Platform Attribute
+              Credential Profile", Specification Version 1.0, Revision
+              16, January 2018,
+              <https://trustedcomputinggroup.org/resource/tcg-platform-
+              attribute-credential-profile/>.
+
+
+
+
+
+ 
+   [PROV-TPM-2.0]
+              Trusted Computing Group, "TCG TPM v2.0 Provisioning
+              Guidance", Version 1.0, Revision 1.0, March 2017,
+              <https://trustedcomputinggroup.org/wp-content/uploads/TCG-
+              TPM-v2.0-Provisioning-Guidance-Published-v1r1.pdf>.
+
+
+
+
+
+ 
+   [RATS-EAT] Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
+              Wallace, "The Entity Attestation Token (EAT)", Work in
+              Progress, Internet-Draft, draft-ietf-rats-eat-31, 6
+              September 2024, <https://datatracker.ietf.org/doc/html/
+              draft-ietf-rats-eat-31>.
+
+
+
+
+
+ 
+   [RATS-INTERACTION-MODELS]
+              Birkholz, H., Eckel, M., Pan, W., and E. Voit, "Reference
+              Interaction Models for Remote Attestation Procedures",
+              Work in Progress, Internet-Draft, draft-ietf-rats-
+              reference-interaction-models-11, 22 July 2024,
+              <https://datatracker.ietf.org/doc/html/draft-ietf-rats-
+              reference-interaction-models-11>.
+
+
+
+
+
+ 
+   [RATS-NET-DEV-SUB]
+              Birkholz, H., Voit, E., and W. Pan, "Attestation Event
+              Stream Subscription", Work in Progress, Internet-Draft,
+              draft-ietf-rats-network-device-subscription-05, 7 July
+              2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
+              rats-network-device-subscription-05>.
+
+
+
+
+
+ 
+   [RATS-TUDA]
+              Fuchs, A., Birkholz, H., McDonald, I., and C. Bormann,
+              "Time-Based Uni-Directional Attestation", Work in
+              Progress, Internet-Draft, draft-birkholz-rats-tuda-07, 10
+              July 2022, <https://datatracker.ietf.org/doc/html/draft-
+              birkholz-rats-tuda-07>.
+
+
+
+
+
+ 
+   [RATS-USECASES]
+              Richardson, M., Wallace, C., and W. Pan, "Use cases for
+              Remote Attestation common encodings", Work in Progress,
+              Internet-Draft, draft-richardson-rats-usecases-08, 2
+              November 2020, <https://datatracker.ietf.org/doc/html/
+              draft-richardson-rats-usecases-08>.
+
+
+
+
+
+ 
+   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
+              Levkowetz, Ed., "Extensible Authentication Protocol
+              (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
+              <https://www.rfc-editor.org/info/rfc3748>.
+
+
+
+
+
+ 
+   [RFC6813]  Salowey, J. and S. Hanna, "The Network Endpoint Assessment
+              (NEA) Asokan Attack Analysis", RFC 6813,
+              DOI 10.17487/RFC6813, December 2012,
+              <https://www.rfc-editor.org/info/rfc6813>.
+
+
+
+
+
+ 
+   [RFC7950]  Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
+              RFC 7950, DOI 10.17487/RFC7950, August 2016,
+              <https://www.rfc-editor.org/info/rfc7950>.
+
+
+
+
+
+ 
+   [RFC8572]  Watsen, K., Farrer, I., and M. Abrahamsson, "Secure Zero
+              Touch Provisioning (SZTP)", RFC 8572,
+              DOI 10.17487/RFC8572, April 2019,
+              <https://www.rfc-editor.org/info/rfc8572>.
+
+
+
+
+
+ 
+   [RFC8995]  Pritikin, M., Richardson, M., Eckert, T., Behringer, M.,
+              and K. Watsen, "Bootstrapping Remote Secure Key
+              Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995,
+              May 2021, <https://www.rfc-editor.org/info/rfc8995>.
+
+
+
+
+
+ 
+   [RFC9525]  Saint-Andre, P. and R. Salz, "Service Identity in TLS",
+              RFC 9525, DOI 10.17487/RFC9525, November 2023,
+              <https://www.rfc-editor.org/info/rfc9525>.
+
+
+
+
+
+ 
+   [SP800-155]
+              NIST, "BIOS Integrity Measurement Guidelines (Draft)",
+              NIST SP 800-155 (Draft), December 2011,
+              <https://csrc.nist.gov/files/pubs/sp/800/155/ipd/docs/
+              draft-sp800-155_dec2011.pdf>.
+
+
+
+
+
+ 
+   [SP800-193]
+              NIST, "Platform Firmware Resiliency Guidelines", NIST
+              SP 800-193, DOI 10.6028/NIST.SP.800-193, May 2018,
+              <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
+              NIST.SP.800-193.pdf>.
+
+
+
+
+
+ 
+   [SWID-GEN] Labs64, "SoftWare IDentification (SWID) Tags Generator
+              (Maven Plugin)",
+              <https://github.com/Labs64/swid-maven-plugin>.
+
+
+
+
+
+ 
+   [TCG-RT]   Trusted Computing Group, "TCG Roots of Trust
+              Specification", (Draft), Family "1.0", Level 00, Revision
+              0.20, July 2018, <https://trustedcomputinggroup.org/wp-
+              content/uploads/
+              TCG_Roots_of_Trust_Specification_v0p20_PUBLIC_REVIEW.pdf>.
+
+
+
+
+
+ 
+   [TPM-1.2]  Trusted Computing Group, "TPM 1.2 Main Specification",
+              Level 2, Version 1.2, Revision 116, March 2011,
+              <https://trustedcomputinggroup.org/resource/tpm-main-
+              specification/>.
+
+
+
+
+
+ 
+   [TPM-2.0]  Trusted Computing Group, "Trusted Platform Module
+              Library", Family "2.0", Level 00, Revision 01.83, March
+              2024, <https://trustedcomputinggroup.org/resource/tpm-
+              library-specification/>.
+
+
+
+
+
+
+Appendix A. Supporting Materials +
+
+
+
+付録A. サポート材料 +
+
+
+
+
+
+A.1. Using a TPM for Attestation +
+
+
+
+A.1. 証明のためにTPMを使用します +
+
+
+
+
+

+The TPM and surrounding ecosystem provide three interlocking capabilities to enable secure collection of evidence from a remote device: PCRs, a Quote mechanism, and a standardized Event Log. +

+
+
+

+TPMと周囲のエコシステムは、PCRS、引用メカニズム、標準化されたイベントログからの証拠の安全な収集を可能にする3つのインターロック機能を提供します。 +

+
+
+
+
+

+Each TPM has at least eight and at most twenty-four PCRs (depending on the profile and vendor choices), each one large enough to hold one hash value (SHA-1, SHA-256, and other hash algorithms can be used, depending on TPM version). PCRs can't be accessed directly from outside the chip, but the TPM interface provides a way to "extend" a new security measurement hash into any PCR, a process by which the existing value in the PCR is hashed with the new security measurement hash, and the result placed back into the same PCR. The result is a composite fingerprint comprising the hash of all the security measurements extended into each PCR since the system was reset. +

+
+
+

+各TPMには、少なくとも8つ以下のPCR（プロファイルとベンダーの選択肢によって異なります）があり、それぞれが1つのハッシュ値を保持するのに十分な大きさです（SHA-1、SHA-256、およびその他のハッシュアルゴリズムは使用できます。TPMバージョンで）。PCRSにチップの外側から直接アクセスすることはできませんが、TPMインターフェイスは、新しいセキュリティ測定ハッシュをPCRに「拡張」する方法を提供します。、および結果が同じPCRに戻りました。その結果、システムがリセットされて以来、各PCRに拡張されたすべてのセキュリティ測定のハッシュを含む複合指紋が作成されます。 +

+
+
+
+
+

+Every time a PCR is extended, an entry should be added to the corresponding Event Log. Logs contain the security measurement hash plus informative fields offering hints as to which event generated the security measurement. The Event Log itself is protected against accidental manipulation, but it is implicitly tamper-evident: Any verification process can read the security measurement hash from the log events, compute the composite value, and compare that to what is in the PCR. If there's no discrepancy, the logs do provide an accurate view of what was placed into the PCR. +

+
+
+

+PCRが延長されるたびに、対応するイベントログにエントリを追加する必要があります。ログには、セキュリティ測定のハッシュと、セキュリティ測定を生成するイベントに関するヒントを提供する有益なフィールドが含まれています。イベントログ自体は偶発的な操作から保護されていますが、暗黙的に改ざんされています。検証プロセスは、ログイベントからセキュリティ測定ハッシュを読み取り、コンポジット値を計算し、それをPCRのものと比較できます。矛盾がない場合、ログはPCRに配置されたものの正確なビューを提供します。 +

+
+
+
+
+

+Note that the composite hash-of-hashes recorded in PCRs is order-dependent, resulting in different PCR values for different ordering of the same set of events (e.g., Event A followed by Event B yields a different PCR value than B followed by A). For single-threaded code, where both the events and their order are fixed, a Verifier may validate a single PCR value, and use the log only to diagnose a mismatch from Reference Values. However, operating system code is usually nondeterministic, meaning that there may never be a single "known good" PCR value. In this case, the Verifier may have to verify that the log is correct, and then analyze each item in the log to determine if it represents an authorized event. +

+
+
+

+PCRSで記録された複合ハッシュオブハッシュは順序依存性であり、同じ一連のイベントの異なる順序付けに対して異なるPCR値をもたらすことに注意してください（たとえば、イベントAが続くイベントBは、Bとは異なるPCR値を生成します。）。イベントとその注文の両方が修正されている単一の読み取りコードの場合、検証者は単一のPCR値を検証し、ログを使用して参照値からの不一致を診断することができます。ただし、オペレーティングシステムコードは通常、無決定的であるため、単一の「既知の良い」PCR値がない場合があります。この場合、検証者はログが正しいことを確認し、ログ内の各アイテムを分析して、承認されたイベントを表すかどうかを判断する必要がある場合があります。 +

+
+
+
+
+

+In a conventional TPM Attestation environment, the first measurement must be made and extended into the TPM by trusted device code (called the RTM). That first measurement should cover the segment of code that is run immediately after the RTM, which then measures the next code segment before running it, and so on, forming an unbroken chain of trust. See [TCG-RT] for more on Mutable vs. Immutable Roots of Trust. +

+
+
+

+従来のTPM証明環境では、信頼できるデバイスコード（RTMと呼ばれる）により、最初の測定を行い、TPMに拡張する必要があります。その最初の測定では、RTMの直後に実行されるコードのセグメントをカバーします。これは、実行する前に次のコードセグメントを測定し、壊れていない信頼のチェーンを形成します。可変性と不変の信頼の根の詳細については、[TCG-RT]を参照してください。 +

+
+
+
+
+

+The TPM provides another mechanism called a Quote that can read the current value of the PCRs and package them, along with the Verifier's nonce, into a TPM-specific data structure signed by an Attestation private key, known only to the TPM. +

+
+
+

+TPMは、PCRSの現在の値を読み取り、検証者のNonCeとともに、TPMのみで知られている証明の秘密鍵によって署名されたTPM固有のデータ構造にパッケージ化できる引用と呼ばれる別のメカニズムを提供します。 +

+
+
+
+
+

+It's important to note that the Quote data structure is signed inside the TPM (see Section 5, Security Considerations). The trust model is preserved by retrieving the Quote in a way that does not invalidate the signature, as specified in [RFC9684]. The structure of the command and response for a quote, including its signature, as generated by the TPM, can be seen in Part 3, Section 16.5, of [TPM-1.2] and Section 18.4.2 of [TPM-2.0]. +

+
+
+

+引用データ構造はTPM内で署名されていることに注意することが重要です（セクション5、セキュリティに関する考慮事項を参照）。信頼モデルは、[RFC9684]で指定されているように、署名を無効にしない方法で引用を取得することにより保存されます。TPMによって生成された署名を含む引用のコマンドの構造と応答は、[TPM-1.2]のパート3、セクション16.5、および[TPM-2.0]のセクション18.4.2で見ることができます。 +

+
+
+
+
+

+The Verifier uses the Quote and Log together. The Quote contains the composite hash of the complete sequence of security measurement hashes, signed by the TPM's private AK. The Log contains a record of each measurement extended into the TPM's PCRs. By computing the composite hash of all the measurements, the Verifier can verify the integrity of the Event Log, even though the Event Log itself is not signed. Each hash in the validated Event Log can then be compared to corresponding expected values in the set of Reference Values to validate overall system integrity. +

+
+
+

+検証器は、引用とログを一緒に使用します。引用には、TPMのプライベートAKが署名したセキュリティ測定ハッシュの完全なシーケンスの複合ハッシュが含まれています。ログには、TPMのPCRSに拡張された各測定の記録が含まれています。すべての測定値の複合ハッシュを計算することにより、イベントログ自体が署名されていない場合でも、検証者はイベントログの整合性を検証できます。検証されたイベントログの各ハッシュは、参照値のセットの対応する期待値と比較して、システム全体の整合性を検証できます。 +

+
+
+
+
+

+A summary of information exchanged in obtaining quotes from TPM 1.2 and TPM 2.0 can be found in [TAP], Section 4. Detailed information about PCRs and Quote data structures can be found in [TPM-1.2], [TPM-2.0]. Recommended log formats include [PC-CLIENT-BIOS-TPM-2.0], and [CEL]. +

+
+
+

+TPM 1.2およびTPM 2.0から引用符を取得する際に交換される情報の要約は、[TAP]、セクション4にあります。PCRSおよび引用データ構造の詳細情報は、[TPM-1.2]、[TPM-2.0]にあります。推奨されるログ形式には、[PC-Client-BIOS-TPM-2.0]および[CEL]が含まれます。 +

+
+
+
+
+
+A.2. Root of Trust for Measurement (RTM) +
+
+
+
+A.2. 測定のための信頼のルート（RTM） +
+
+
+
+
+

+The measurements needed for attestation require that the device being attested is equipped with an RTM, that is, some trustworthy mechanism that can compute the first measurement in the chain of trust required to attest that each stage of system startup is verified, a Root of Trust for Storage (i.e., the TPM PCRs) to record the results, and a Root of Trust for Reporting to report the results. +

+
+
+

+証明に必要な測定では、証明されているデバイスにRTM、つまり、システムスタートアップの各段階が検証されていることを証明するために必要な信頼チェーンで最初の測定値を計算できる信頼できるメカニズムが装備されていることが必要です。ストレージ（つまり、TPM PCRS）の場合、結果を記録し、結果を報告する報告のための信頼の根が記録されます。 +

+
+
+
+
+

+While there are many complex aspects of Roots of Trust ([TCG-RT] [SP800-155] [SP800-193]), two aspects that are important in the case of attestation are: +

+
+
+

+信頼のルーツには多くの複雑な側面がありますが（[TCG-RT] [SP800-155] [SP800-193]）、証明の場合に重要な2つの側面は次のとおりです。 +

+
+
+
+
+

+* The first measurement computed by the RTM and stored in the TPM's Root of Trust for Storage must be assumed to be correct. +

+
+
+

+* RTMによって計算され、TPMのストレージの信頼ルートに保存された最初の測定は、正しいと想定する必要があります。 +

+
+
+
+
+

+* There must not be a way to reset the Root of Trust for Storage without re-entering the RTM code. +

+
+
+

+* RTMコードに再び入ることなく、ストレージのために信頼のルートをリセットする方法があってはなりません。 +

+
+
+
+
+

+The first measurement must be computed by code that is implicitly trusted; if that first measurement can be subverted, none of the remaining measurements can be trusted. (See [SP800-155].) +

+
+
+

+最初の測定は、暗黙的に信頼されるコードによって計算する必要があります。その最初の測定が破壊される可能性がある場合、残りの測定値はどれも信頼できません。（[SP800-155]を参照してください。） +

+
+
+
+
+

+It's important to note that the trustworthiness of the RTM code cannot be assured by the TPM or TPM supplier -- code or procedures external to the TPM must guarantee the security of the RTM. +

+
+
+

+RTMコードの信頼性はTPMまたはTPMサプライヤーによって保証されないことに注意することが重要です。TPMの外部のコードまたは手順は、RTMのセキュリティを保証する必要があります。 +

+
+
+
+
+
+A.3. Layering Model for Network Equipment Attester and Verifier +
+
+
+
+A.3. ネットワーク機器の階層モデルは、攻撃と検証装置を階層化します +
+
+
+
+
+

+Retrieval of identity and attestation state uses one protocol stack, while retrieval of Reference Values uses a different set of protocols. Figure 5 shows the components involved. +

+
+
+

+IDと証明状態の検索は1つのプロトコルスタックを使用し、参照値の取得は異なるプロトコルセットを使用します。図5は、関係するコンポーネントを示しています。 +

+
+
+
+
+ 
+   +-----------------------+              +-------------------------+
+   |                       |              |                         |
+   |       Attester        |<-------------|        Verifier         |
+   |       (Device)        |------------->|   (Management Station)  |
+   |                       |      |       |                         |
+   +-----------------------+      |       +-------------------------+
+                                  |
+              -------------------- --------------------
+              |                                        |
+   -------------------------------    ---------------------------------
+   |      Reference Values       |    |          Attestation          |
+   -------------------------------    ---------------------------------
+
+   ********************************************************************
+   *           IETF Remote Attestation Conceptual Data Flow           *
+   *                        RFC9334, Figure 1                         *
+   ********************************************************************
+
+       .........................          .........................
+       .  Reference Integrity  .          .       TAP Info        .
+       .       Manifest        .          .  Model and Canonical  .
+       .                       .          .      Log Format       .
+       .........................          .........................
+
+       *************************          *************************
+       *    YANG SWID Module   *          *    YANG Attestation   *
+       *       RFC9393         *          *        Module         *
+       *                       *          *        RFC9684        *
+       *                       *          *                       *
+       *************************          *************************
+
+       *************************          *************************
+       * XML, JSON, CBOR, etc. *          * XML, JSON, CBOR, etc. *
+       *************************          *************************
+
+       *************************          *************************
+       *   RESTCONF/NETCONF    *          *   RESTCONF/NETCONF    *
+       *************************          *************************
+
+       *************************          *************************
+       *       TLS, SSH        *          *       TLS, SSH        *
+       *************************          *************************
+
+
+
+
+
+

+Figure 5: RIV Protocol Stacks +

+
+
+

+図5：RIVプロトコルスタック +

+
+
+
+
+

+IETF documents are captured in boxes surrounded by asterisks. TCG documents are shown in boxes surrounded by dots. +

+
+
+

+IETFドキュメントは、アスタリスクに囲まれたボックスでキャプチャされます。TCGドキュメントは、ドットに囲まれたボックスに表示されます。 +

+
+
+
+
+
+A.4. Implementation Notes +
+
+
+
+A.4. 実装ノート +
+
+
+
+
+

+Table 2 summarizes many of the actions needed to complete an Attestation system, with links to relevant documents. While documents are controlled by several standards organizations, the implied actions required for implementation are all the responsibility of the manufacturer of the device, unless otherwise noted. +

+
+
+

+表2は、関連するドキュメントへのリンクを使用して、証明システムを完了するために必要なアクションの多くをまとめたものです。文書はいくつかの標準組織によって管理されていますが、特に明記しない限り、実装に必要な黙示的な行動はすべて、デバイスの製造業者の責任です。 +

+
+
+
+
+

+As noted, SWID tags can be generated many ways, but one possible tool is [SWID-GEN]. +

+
+
+

+前述のように、SWIDタグは多くの方法で生成できますが、可能なツールの1つは[Swid-Gen]です。 +

+
+
+
+
+ 
+   +========================================+==========================+
+   | Component                              | Controlling              |
+   |                                        | Specification            |
+   +========================================+==========================+
+   | Make a Secure execution environment:   | [TCG-RT]                 |
+   |                                        |                          |
+   | *  Attestation depends on a secure     | <www.uefi.org>           |
+   |    RTM outside the TPM, as well as     |                          |
+   |    Roots for Storage and Reporting     |                          |
+   |    inside the TPM.                     |                          |
+   |                                        |                          |
+   | *  Refer to "TCG Roots of Trust        |                          |
+   |    Specification" [TCG-RT].            |                          |
+   |                                        |                          |
+   | *  [SP800-193] also provides           |                          |
+   |    guidelines on Roots of Trust.       |                          |
+   +----------------------------------------+--------------------------+
+   | Provision the TPM as described in the  | [PLATFORM-DEVID-TPM-2.0] |
+   | TCG documents.                         |                          |
+   |                                        | [PLATFORM-CERTS]         |
+   +----------------------------------------+--------------------------+
+   | Put a DevID or Platform Certificate    | [PLATFORM-DEVID-TPM-2.0] |
+   | in the TPM:                            |                          |
+   |                                        | [PLATFORM-CERTS]         |
+   | *  Install an IAK at the same time so  |                          |
+   |    that Attestation can work out of    |                          |
+   |    the box.                            |                          |
+   |                                        |                          |
+   | *  Equipment suppliers and owners may  |                          |
+   |    want to implement LDevID as well    |                          |
+   |    as IDevID.                          |                          |
+   |                                        +--------------------------+
+   |                                        | [IEEE-802-1AR]           |
+   +----------------------------------------+--------------------------+
+   | Connect the TPM to the TLS stack:      | Vendor TLS stack (This   |
+   |                                        | action configures TLS to |
+   | *  Use the DevID in the TPM to         | use the DevID as its     |
+   |    authenticate TAP connections,       | client certificate.)     |
+   |    identifying the device.             |                          |
+   +----------------------------------------+--------------------------+
+   | Make CoSWID tags for BIOS/Loader/      | [RFC9393]                |
+   | Kernel objects:                        |                          |
+   |                                        | [SWID]                   |
+   | *  Add reference measurements into     |                          |
+   |    SWID tags.                          | [NIST-IR-8060]           |
+   |                                        |                          |
+   | *  Manufacturer should sign the SWID   |                          |
+   |    tags.                               |                          |
+   |                                        |                          |
+   | *  The TCG RIM-IM [RIM] identifies     |                          |
+   |    further procedures to create        |                          |
+   |    signed RIM documents that provide   |                          |
+   |    the necessary reference             |                          |
+   |    information.                        |                          |
+   +----------------------------------------+--------------------------+
+   | Package the SWID tags with a vendor    | Retrieve tags with       |
+   | software release:                      | [RFC9393].               |
+   |                                        |                          |
+   | *  A tag-generator plugin such as      |                          |
+   |    [SWID-GEN] can be used.             |                          |
+   |                                        +--------------------------+
+   |                                        | [PC-CLIENT-RIM]          |
+   +----------------------------------------+--------------------------+
+   | Use PC Client measurement definitions  | [PC-CLIENT-BIOS-TPM-2.0] |
+   | to define the use of PCRs (although    |                          |
+   | Windows OS is rare on Networking       |                          |
+   | Equipment, UEFI BIOS is not).          |                          |
+   +----------------------------------------+--------------------------+
+   | Use TAP to retrieve measurements:      | [RFC9684]                |
+   |                                        |                          |
+   | *  Map to YANG.                        | [CEL]                    |
+   |                                        |                          |
+   | *  Use Canonical Log Format.           |                          |
+   +----------------------------------------+--------------------------+
+   | A Verifier (as described in            |                          |
+   | [RFC9334], Section 3) should request   |                          |
+   | the attestation and analyze the        |                          |
+   | result.  The Verifier application      |                          |
+   | might be broken down to several more   |                          |
+   | components:                            |                          |
+   |                                        |                          |
+   | *  A Posture Manager Server that       |                          |
+   |    collects reports and stores them    |                          |
+   |    in a database.                      |                          |
+   |                                        |                          |
+   | *  One or more Analyzers that can      |                          |
+   |    look at the results and figure out  |                          |
+   |    what it means.                      |                          |
+   +----------------------------------------+--------------------------+
+
+
+
+
+
+

+Table 2: Component Status +

+
+
+

+表2：コンポーネントステータス +

+
+
+
+
+
+Acknowledgements +
+
+
+
+謝辞 +
+
+
+
+
+

+The authors wish to thank numerous reviewers for generous assistance, including William Bellingrath, Mark Baushke, Ned Smith, Henk Birkholz, Tom Laffey, Dave Thaler, Wei Pan, Michael Eckel, Thomas Hardjono, Bill Sulzen, Willard (Monty) Wiseman, Kathleen Moriarty, Nancy Cam-Winget, and Shwetha Bhandari. +

+
+
+

+著者は、ウィリアム・ベリングラス、マーク・バウシュケ、ネッド・スミス、ヘンク・バークホルツ、トム・ラフィー、デイブ・ターラー、ウェイ・パン、マイケル・エッケル、トーマス・ハードジョノ、ビル・スルゼン、ウィラード（モンティ）ワイズマン、カトリーン・モリルティアティルティアン・モリエン・モリアルティアの寛大な支援について、多数のレビュアーに感謝したいと考えています。、ナンシー・カム・ウィンゲット、シュエサ・バンダリ。 +

+
+
+
+
+
+Authors' Addresses +
+
+
+
+著者のアドレス +
+
+
+
+
+ 
+   Guy C. Fedorkow (editor)
+   Juniper Networks, Inc.
+   10 Technology Park Drive
+   Westford, Massachusetts 01886
+   United States of America
+   Email: gfedorkow@juniper.net
+
+
+
+
+
+ 
+   Eric Voit
+   Cisco Systems
+   Email: evoit@cisco.com
+
+
+
+
+
+ 
+   Jessica Fitzgerald-McKay
+   National Security Agency
+   9800 Savage Road
+   Ft. Meade, Maryland 20755
+   United States of America
+   Email: jmfitz2@nsa.gov
+
+
+
+
+ + + diff --git a/html/rfc9684.html b/html/rfc9684.html new file mode 100644 index 000000000..b3568fc43 --- /dev/null +++ b/html/rfc9684.html @@ -0,0 +1,4521 @@ + + + + + + RFC 9684 - A YANG Data Model for Challenge-Response-Based Remote Attestation (CHARRA) Procedures Using Trusted Platform Modules (TPMs) 日本語訳 + + + + + + + + + + + + +
+
+ + + +
+
+
+ + +
+
+
+ 
+Internet Engineering Task Force (IETF)                       H. Birkholz
+Request for Comments: 9684                                      M. Eckel
+Category: Standards Track                        Fraunhofer SIT | ATHENE
+ISSN: 2070-1721                                              S. Bhandari
+                                                             ThoughtSpot
+                                                                 E. Voit
+                                                               B. Sulzen
+                                                                   Cisco
+                                                                  L. Xia
+                                                                  Huawei
+                                                               T. Laffey
+                                                                     HPE
+                                                          G. C. Fedorkow
+                                                                 Juniper
+                                                           December 2024
+
+
+
+
+
+
+A YANG Data Model for Challenge-Response-Based Remote Attestation (CHARRA) Procedures Using Trusted Platform Modules (TPMs) +
+
+
+
+信頼できるプラットフォームモジュール（TPM）を使用したチャレンジ応答ベースのリモート証明（Charra）手順のYangデータモデル +
+
+
+
+
+
+Abstract +
+
+
+
+概要 +
+
+
+
+
+

+This document defines the YANG Remote Procedure Calls (RPCs) and configuration nodes that are required to retrieve attestation evidence about integrity measurements from a device, following the operational context defined in RFC 9683 "TPM-based Network Device Remote Integrity Verification". Complementary measurement logs originating from one or more Roots of Trust for Measurement (RTMs) are also provided by the YANG RPCs. The defined module requires the inclusion of the following in the device components of the composite device on which the YANG server is running: at least one Trusted Platform Module (TPM) of either version 1.2 or 2.0 as well as a corresponding TPM Software Stack (TSS), or an equivalent hardware implementation that includes the protected capabilities as provided by TPMs as well as a corresponding software stack. +

+
+
+

+このドキュメントでは、RFC 9683「TPMベースのネットワークデバイスリモートインテグリティ検証」で定義されている運用コンテキストに従って、デバイスからの整合性測定に関する証明の証拠を取得するために必要なYangリモートプロシージャコール（RPC）と構成ノードを定義します。測定のための1つ以上の信頼のルート（RTMS）に由来する補完測定ログも、Yang RPCによって提供されます。定義されたモジュールでは、Yangサーバーが実行されている複合デバイスのデバイスコンポーネントに次のものを含める必要があります。バージョン1.2または2.0のいずれかの少なくとも1つの信頼できるプラットフォームモジュール（TPM）と対応するTPMソフトウェアスタック（TSS）、またはTPMSと対応するソフトウェアスタックによって提供される保護された機能を含む同等のハードウェア実装。 +

+
+
+
+
+
+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/rfc9684. +

+
+
+

+このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9684で取得できます。 +

+
+
+
+
+
+Copyright Notice +
+
+
+
+著作権表示 +
+
+
+
+
+

+Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. +

+
+
+

+著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。 +

+
+
+
+
+

+This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. +

+
+
+

+このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。 +

+
+
+
+
+
+Table of Contents +
+
+
+
+目次 +
+
+
+
+
+ 
+   1.  Introduction
+     1.1.  Requirements Notation
+   2.  The YANG Module for Basic Remote Attestation Procedures
+     2.1.  YANG Modules
+       2.1.1.  ietf-tpm-remote-attestation
+       2.1.2.  ietf-tcg-algs
+   3.  IANA Considerations
+   4.  Security Considerations
+   5.  References
+     5.1.  Normative References
+     5.2.  Informative References
+   Appendix A.  Integrity Measurement Architecture (IMA)
+   Appendix B.  IMA for Network Equipment Boot Logs
+   Authors' Addresses
+
+
+
+
+
+
+1. Introduction +
+
+
+
+1. はじめに +
+
+
+
+
+

+This document is based on the general terminology defined in Remote ATtestation procedureS (RATS) architecture [RFC9334] and uses the operational context defined in [RFC9683] as well as the interaction model and information elements defined in [RATS-Interaction-Models]. The currently supported hardware security modules (HSMs) are the Trusted Platform Modules (TPMs) [TPM1.2] [TPM2.0] as specified by the Trusted Computing Group (TCG). One TPM, or multiple TPMs in the case of a composite device, is required in order to use the YANG module defined in this document. Each TPM is used as a Root of Trust for Storage (RTS) in order to store system security measurement Evidence. And each TPM is used as a Root of Trust for Reporting (RTR) in order to retrieve attestation Evidence. This is done by using a YANG RPC to request a quote that exposes a rolling hash of the security measurements held internally within the TPM. +

+
+
+

+このドキュメントは、リモート認証手順（RAT）アーキテクチャ[RFC9334]で定義されている一般的な用語に基づいており、[RFC9683]で定義されている運用コンテキストと、[RATS-Interaction-Models]で定義された相互作用モデルと情報要素を使用します。現在サポートされているハードウェアセキュリティモジュール（HSM）は、信頼できるコンピューティンググループ（TCG）で指定されている信頼できるプラットフォームモジュール（TPMS）[TPM1.2] [TPM2.0]です。このドキュメントで定義されているYangモジュールを使用するには、複合デバイスの場合の1つのTPM、または複数のTPMが必要です。各TPMは、システムセキュリティ測定の証拠を保存するために、ストレージ（RTS）の信頼のルートとして使用されます。また、各TPMは、証拠の証拠を取得するために、レポート（RTR）の信頼のルートとして使用されます。これは、Yang RPCを使用して、TPM内で内部に保持されているセキュリティ測定値のローリングハッシュを公開する引用をリクエストすることによって行われます。 +

+
+
+
+
+

+Specific terms imported from [RFC9334] and used in this document include Attester, composite device, and Evidence. +

+
+
+

+[RFC9334]からインポートされ、このドキュメントで使用されている特定の用語には、Attester、複合装置、および証拠が含まれます。 +

+
+
+
+
+

+Specific terms imported from [TPM2.0-Key] and used in this document include Endorsement Key (EK), Initial Attestation Key (IAK), Attestation Identity Key (AIK), and Local Attestation Key (LAK). +

+
+
+

+[TPM2.0-KEY]からインポートされ、このドキュメントで使用されている特定の用語には、承認キー（EK）、初期証明キー（IAK）、証明IDキー（AIK）、およびローカル証明キー（LAK）が含まれます。 +

+
+
+
+
+
+1.1. Requirements Notation +
+
+
+
+1.1. 要件表記 +
+
+
+
+
+

+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. +

+
+
+

+「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。 +

+
+
+
+
+
+2. The YANG Module for Basic Remote Attestation Procedures +
+
+
+
+2. 基本的なリモート証明手順のためのYangモジュール +
+
+
+
+
+

+One or more TPMs MUST be embedded in a composite device that provides attestation Evidence via the YANG module defined in this document. The ietf-tpm-remote-attestation YANG module enables a composite device to take on the role of an Attester, in accordance with the RATS architecture [RFC9334] and the corresponding challenge-response interaction model defined in [RATS-Interaction-Models]. A fresh nonce with an appropriate amount of entropy [NIST-915121] MUST be supplied by the YANG client in order to enable a proof-of-freshness with respect to the attestation Evidence provided by the Attester running the YANG datastore. Further, this nonce is used to prevent replay attacks. The method for communicating the relationship of each individual TPM to the specific measured component within the composite device is out of the scope of this document. +

+
+
+

+このドキュメントで定義されているYangモジュールを介して証明の証拠を提供する複合デバイスに1つ以上のTPMを埋め込む必要があります。IETF-TPM-Remote-Attestation Yangモジュールは、[RFC9334]および[RATS-Interaction-Models]で定義された対応する課題と課題との対応相互作用モデルに従って、複合デバイスが攻撃者の役割を引き受けることを可能にします。適切な量のエントロピー[NIST-915121]を備えた新鮮な非CEは、Yangデータストアを実行しているAttesterが提供する証明の証拠に関して新鮮な証明を可能にするために、Yangクライアントから提供する必要があります。さらに、このノンセは、リプレイ攻撃を防ぐために使用されます。個々のTPMの関係を複合デバイス内の特定の測定コンポーネントと通信する方法は、このドキュメントの範囲外です。 +

+
+
+
+
+
+2.1. YANG Modules +
+
+
+
+2.1. ヤンモジュール +
+
+
+
+
+

+In this section, the two YANG modules are defined. +

+
+
+

+このセクションでは、2つのYangモジュールが定義されています。 +

+
+
+
+
+
+2.1.1. ietf-tpm-remote-attestation +
+
+
+
+2.1.1. IETF-TPM-Remote-Attestation +
+
+
+
+
+

+This YANG module imports modules from [RFC6991] with prefix 'yang', [RFC8348] with prefix 'hw', [RFC9642] with prefix 'ks', and ietf-tcg-algs.yang Section 2.1.2.3 with prefix 'taa'. Additionally, references are made to [RFC6933], [TPM1.2-Commands], [TPM2.0-Arch], [TPM2.0-Structures], [TPM2.0-Key], [TPM1.2-Structures], [BIOS-Log], and [CEL], as well as Appendix B. +

+
+
+

+このYangモジュールは、[RFC6991]からモジュールをプレフィックス「YANG」、[RFC8348]、プレフィックス「HW」、[RFC9642]をプレフィックス「KS」、IETF-TCG-ALGS.YANGセクション2.1.2.3でプレフィックス「TAA」とともにインポートします。。さらに、参照は[RFC6933]、[TPM1.2-Commands]、[TPM2.0-Arch]、[TPM2.0-fructures]、[TPM2.0-KEY]、[TPM1.2-structures]、[TPM2.0-Key]、[TPM2.0-KEY]、[TPM2.0-KEY]、[bios-log]、および[cel]、および付録B +

+
+
+
+
+
+2.1.1.1. Features +
+
+
+
+2.1.1.1. 特徴 +
+
+
+
+
+

+This module supports the following features: +

+
+
+

+このモジュールは、次の機能をサポートしています。 +

+
+
+
+
+

+'mtpm': +

+
+
+

+「mtpm」： +

+
+
+
+
+

+Indicates that multiple TPMs on the device can support remote attestation. For example, this feature could be used in cases where multiple line cards are present, each with its own TPM. +

+
+
+

+デバイス上の複数のTPMがリモートの証明をサポートできることを示します。たとえば、この機能は、複数のラインカードが存在する場合に使用でき、それぞれ独自のTPMがあります。 +

+
+
+
+
+

+'bios': +

+
+
+

+「bios」： +

+
+
+
+
+

+Indicates that the device supports the retrieval of BIOS and Unified Extensible Firmware Interface (UEFI) event logs [BIOS-Log]. +

+
+
+

+デバイスは、BIOSおよび統合された拡張可能なファームウェアインターフェイス（UEFI）イベントログ[BIOS-LOG]の検索をサポートしていることを示します。 +

+
+
+
+
+

+'ima': +

+
+
+

+「イマ」： +

+
+
+
+
+

+Indicates that the device supports the retrieval of event logs from the Linux Integrity Measurement Architecture (IMA, see Appendix A). +

+
+
+

+このデバイスは、Linux Integrity測定アーキテクチャからのイベントログの取得をサポートしていることを示します（IMA、付録Aを参照）。 +

+
+
+
+
+

+'netequip_boot': +

+
+
+

+'net quip_boot'： +

+
+
+
+
+

+Indicates that the device supports the retrieval of netequip boot event logs. See Appendixes A and B. +

+
+
+

+デバイスがNet Quip Bootイベントログの取得をサポートしていることを示します。付録AとBを参照してください。 +

+
+
+
+
+
+2.1.1.2. Identities +
+
+
+
+2.1.1.2. アイデンティティ +
+
+
+
+
+

+This module supports the following types of attestation event logs: 'bios', 'ima', and 'netequip_boot'. +

+
+
+

+このモジュールは、「BIOS」、「IMA」、および「net quip_boot」の証明イベントログの次の種類をサポートしています。 +

+
+
+
+
+
+2.1.1.3. Remote Procedure Calls (RPCs) +
+
+
+
+2.1.1.3. リモートプロシージャコール（RPC） +
+
+
+
+
+

+In the following sections, RPCs for attestation procedures for both TPM 1.2 and TPM 2.0 are defined. +

+
+
+

+次のセクションでは、TPM 1.2とTPM 2.0の両方の証明手順のRPCが定義されています。 +

+
+
+
+
+
+2.1.1.3.1. tpm12-challenge-response-attestation +
+
+
+
+2.1.1.3.1. TPM12-Challenge-Response-Attestation +
+
+
+
+
+

+This RPC allows a Verifier to request via the _TPM Quote_ operation, signed TPM Platform Configuration Registers (PCRs) from a cryptoprocessor compliant with TPM 1.2. Where the feature 'mtpm' is active, and one or more 'certificate-name' is not provided, all cryptoprocessors compliant with TPM 1.2 will respond. The YANG tree diagram of this RPC is as follows: +

+
+
+

+このRPCにより、検証者は_TPM QUOTE_操作を介して要求できます。TPM1.2に準拠した暗号化プロセッサからTPMプラットフォーム構成レジスタ（PCR）に署名されます。機能「mtpm」がアクティブであり、1つ以上の「証明書名」が提供されていない場合、すべての暗号プロセッサがTPM 1.2に準拠しています。このRPCのヤンツリー図は次のとおりです。 +

+
+
+
+
+ 
+   +---x tpm12-challenge-response-attestation {taa:tpm12}?
+      +---w input
+      |  +---w tpm12-attestation-challenge
+      |     +---w pcr-index*          pcr
+      |     +---w nonce-value         binary
+      |     +---w certificate-name*   certificate-name-ref
+      |             {tpm:mtpm}?
+      +--ro output
+         +--ro tpm12-attestation-response* []
+            +--ro certificate-name    certificate-name-ref
+            +--ro up-time?            uint32
+            +--ro TPM_QUOTE2?         binary
+
+
+
+
+
+
+2.1.1.3.2. tpm20-challenge-response-attestation +
+
+
+
+2.1.1.3.2. TPM20-Challenge-Response-Attestation +
+
+
+
+
+

+This RPC allows a Verifier to request signed TPM PCRs (_TPM Quote_ operation) from a cryptoprocessor compliant with TPM 2.0. Where the feature 'mtpm' is active, and one or more 'certificate-name' is not provided, all cryptoprocessors compliant with TPM 2.0 will respond. The YANG tree diagram of this RPC is as follows: +

+
+
+

+このRPCを使用すると、検証者は、TPM 2.0に準拠したクリプトプロセッサから署名されたTPM PCRS（_TPM QUOTE_操作）を要求できます。機能「mtpm」がアクティブであり、1つ以上の「証明書名」が提供されていない場合、すべての暗号プロセッサがTPM 2.0に準拠しています。このRPCのヤンツリー図は次のとおりです。 +

+
+
+
+
+ 
+   +---x tpm20-challenge-response-attestation {taa:tpm20}?
+      +---w input
+      |  +---w tpm20-attestation-challenge
+      |     +---w nonce-value            binary
+      |     +---w tpm20-pcr-selection* []
+      |     |  +---w tpm20-hash-algo?   identityref
+      |     |  +---w pcr-index*         pcr
+      |     +---w certificate-name*      certificate-name-ref
+      |             {tpm:mtpm}?
+      +--ro output
+         +--ro tpm20-attestation-response* []
+            +--ro certificate-name       certificate-name-ref
+            +--ro TPMS_QUOTE_INFO        binary
+            +--ro quote-signature?       binary
+            +--ro up-time?               uint32
+            +--ro unsigned-pcr-values* []
+               +--ro tpm20-hash-algo?   identityref
+               +--ro pcr-values* [pcr-index]
+                  +--ro pcr-index    pcr
+                  +--ro pcr-value?   binary
+
+
+
+
+
+

+An example of an RPC challenge requesting PCRs 0-7 from a SHA-256 bank could look like the following: +

+
+
+

+SHA-256銀行からPCRS 0-7を要求するRPCチャレンジの例は、次のように見えることができます。 +

+
+
+
+
+ 
+   <rpc message-id="101"
+     xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
+     <tpm20-attestation-challenge
+       xmlns="urn:ietf:params:xml:ns:yang:ietf-tpm-remote-attestation">
+       <certificate-name>
+           (identifier of a TPM signature key with which the Attester is
+           supposed to sign the attestation data)
+       </certificate-name>
+       <nonce>
+       0xe041307208d9f78f5b1bbecd19e2d152ad49de2fc5a7d8dbf769f6b8ffdeab9
+       </nonce>
+       <tpm20-pcr-selection>
+         <tpm20-hash-algo
+             xmlns="urn:ietf:params:xml:ns:yang:ietf-tcg-algs">
+           TPM_ALG_SHA256
+         </tpm20-hash-algo>
+         <pcr-index>0</pcr-index>
+         <pcr-index>1</pcr-index>
+         <pcr-index>2</pcr-index>
+         <pcr-index>3</pcr-index>
+         <pcr-index>4</pcr-index>
+         <pcr-index>5</pcr-index>
+         <pcr-index>6</pcr-index>
+         <pcr-index>7</pcr-index>
+       </tpm20-pcr-selection>
+     </tpm20-attestation-challenge>
+   </rpc>
+
+
+
+
+
+

+A successful response could be formatted as follows: +

+
+
+

+成功した応答は、次のようにフォーマットできます。 +

+
+
+
+
+ 
+   <rpc-reply message-id="101"
+     xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
+     <tpm20-attestation-response
+       xmlns="urn:ietf:params:xml:ns:yang:ietf-tpm-remote-attestation">
+       <certificate-name
+           xmlns="urn:ietf:params:xml:ns:yang:ietf-keystore">
+           (instance of certificate name in the keystore)
+       </certificate-name>
+       <attestation-data>
+          (raw attestation data, i.e., the TPM quote; this includes,
+          among other information, a composite digest of requested PCRs,
+          the nonce, and TPM 2.0 clock information.)
+       </attestation-data>
+       <quote-signature>
+           (signature over attestation-data using the TPM key
+           identified by sig-key-id)
+       </quote-signature>
+     </tpm20-attestation-response>
+   </rpc-reply>
+
+
+
+
+
+
+2.1.1.4. log-retrieval +
+
+
+
+2.1.1.4. log-retrieval +
+
+
+
+
+

+This RPC allows a Verifier to acquire the Evidence that was extended into specific TPM PCRs. The YANG tree diagram of this RPC is as follows: +

+
+
+

+このRPCにより、検証者は特定のTPM PCRSに拡張された証拠を取得できます。このRPCのヤンツリー図は次のとおりです。 +

+
+
+
+
+ 
+   +---x log-retrieval
+      +---w input
+      |  +---w log-type        identityref
+      |  +---w log-selector* []
+      |     +---w name*                      string
+      |     +---w (index-type)?
+      |     |  +--:(last-entry)
+      |     |  |  +---w last-entry-value?    binary
+      |     |  +--:(index)
+      |     |  |  +---w last-index-number?   uint64
+      |     |  +--:(timestamp)
+      |     |     +---w timestamp?           yang:date-and-time
+      |     +---w log-entry-quantity?        uint16
+      +--ro output
+         +--ro system-event-logs
+            +--ro node-data* []
+               +--ro name?         string
+               +--ro up-time?      uint32
+               +--ro log-result
+                  +--ro (attested_event_log_type)
+                     +--:(bios) {bios}?
+                     |  +--ro bios-event-logs
+                     |     +--ro bios-event-entry* [event-number]
+                     |        +--ro event-number    uint32
+                     |        +--ro event-type?     uint32
+                     |        +--ro pcr-index?      pcr
+                     |        +--ro digest-list* []
+                     |        |  +--ro hash-algo?   identityref
+                     |        |  +--ro digest*      binary
+                     |        +--ro event-size?     uint32
+                     |        +--ro event-data*     binary
+                     +--:(ima) {ima}?
+                     |  +--ro ima-event-logs
+                     |     +--ro ima-event-entry* [event-number]
+                     |        +--ro event-number              uint64
+                     |        +--ro ima-template?             string
+                     |        +--ro filename-hint?            string
+                     |        +--ro filedata-hash?            binary
+                     |        +--ro filedata-hash-algorithm?  string
+                     |        +--ro template-hash-algorithm?  string
+                     |        +--ro template-hash?            binary
+                     |        +--ro pcr-index?                pcr
+                     |        +--ro signature?                binary
+                     +--:(netequip_boot) {netequip_boot}?
+                        +--ro boot-event-logs
+                           +--ro boot-event-entry* [event-number]
+                              +--ro event-number              uint64
+                              +--ro ima-template?             string
+                              +--ro filename-hint?            string
+                              +--ro filedata-hash?            binary
+                              +--ro filedata-hash-algorithm?  string
+                              +--ro template-hash-algorithm?  string
+                              +--ro template-hash?            binary
+                              +--ro pcr-index?                pcr
+                              +--ro signature?                binary
+
+
+
+
+
+
+2.1.1.5. Data Nodes +
+
+
+
+2.1.1.5. データノード +
+
+
+
+
+

+This section provides a high-level description of the data nodes that contain the configuration and operational objects within the YANG data model. For more details, please see the YANG module itself in Figure 1. +

+
+
+

+このセクションでは、Yangデータモデル内の構成と動作オブジェクトを含むデータノードの高レベルの説明を提供します。詳細については、図1のYangモジュール自体を参照してください。 +

+
+
+
+
+

+Container 'rats-support-structures': +

+
+
+

+コンテナ「ラット - サポート構造」： +

+
+
+
+
+

+This houses the set of information relating to remote attestation for a device. This includes specific device TPM(s), the compute nodes (such as line cards) on which the TPM(s) reside, and the algorithms supported across the platform. +

+
+
+

+これにより、デバイスのリモート認証に関する情報のセットがあります。これには、特定のデバイスTPM、TPM（S）が存在するコンピューティングノード（ラインカードなど）、およびプラットフォーム全体でサポートされるアルゴリズムが含まれます。 +

+
+
+
+
+

+Container 'tpms': +

+
+
+

+コンテナ 'tpms'： +

+
+
+
+
+

+This provides configuration and operational details for each supported TPM, including the tpm-firmware-version, PCRs that may be quoted, certificates that are associated with that TPM, and the current operational status. Of note are the certificates that are associated with that TPM. As a certificate is associated with a particular TPM Attestation Key, knowledge of the certificate allows a specific TPM to be identified. +

+
+
+

+これにより、TPM-Firmware-version、引用できるPCR、そのTPMに関連付けられている証明書、現在の運用ステータスなど、サポートされている各TPMの構成と運用の詳細が提供されます。注目すべきは、そのTPMに関連付けられている証明書です。証明書は特定のTPM証明キーに関連付けられているため、証明書の知識により、特定のTPMを特定できます。 +

+
+
+
+
+ 
+   +--rw tpms
+      +--rw tpm* [name]
+         +--rw name                string
+         +--ro hardware-based      boolean
+         +--ro physical-index?     int32 {hw:entity-mib}?
+         +--ro path?               string
+         +--ro compute-node        compute-node-ref {tpm:mtpm}?
+         +--ro manufacturer?       string
+         +--rw firmware-version    identityref
+         +--rw tpm12-hash-algo?    identityref {taa:tpm12}?
+         +--rw tpm12-pcrs*         pcr
+         +--rw tpm20-pcr-bank* [tpm20-hash-algo]  {taa:tpm20}?
+         |  +--rw tpm20-hash-algo    identityref
+         |  +--rw pcr-index*         tpm:pcr
+         +--ro status              enumeration
+         +--rw certificates
+            +--rw certificate* [name]
+               +--rw name            string
+               +--rw keystore-ref?   leafref {ks:asymmetric-keys}?
+               +--rw type?           enumeration
+
+
+
+
+
+

+Container 'attester-supported-algos': +

+
+
+

+コンテナ「Astester-Supported-Algos」： +

+
+
+
+
+

+This identifies which TCG hash algorithms are available for use on the Attesting platform. An operator will use this information to limit algorithms available for use by RPCs to just a desired set from the universe of all hash algorithms allowed by the TCG. +

+
+
+

+これは、どのTCGハッシュアルゴリズムが証明プラットフォームで使用できるかを識別します。オペレーターは、この情報を使用して、RPCが使用できるアルゴリズムを、TCGで許可されたすべてのハッシュアルゴリズムのユニバースから目的のセットに限ります。 +

+
+
+
+
+ 
+   +--rw attester-supported-algos
+      +--rw tpm12-asymmetric-signing*   identityref {taa:tpm12}?
+      +--rw tpm12-hash*                 identityref {taa:tpm12}?
+      +--rw tpm20-asymmetric-signing*   identityref {taa:tpm20}?
+      +--rw tpm20-hash*                 identityref {taa:tpm20}?
+
+
+
+
+
+

+Container 'compute-nodes': +

+
+
+

+コンテナ「計算ノード」： +

+
+
+
+
+

+When there is more than one TPM supported, this container maintains the set of information related to the compute node associated with a specific TPM. This allows each specific TPM to identify to which 'compute-node' it belongs. +

+
+
+

+複数のTPMがサポートされている場合、このコンテナは、特定のTPMに関連付けられた計算ノードに関連する情報セットを維持します。これにより、特定の各TPMが属する「計算ノード」を特定できるようになります。 +

+
+
+
+
+ 
+   +--rw compute-nodes {tpm:mtpm}?
+      +--ro compute-node* [node-id]
+         +--ro node-id                string
+         +--ro node-physical-index?   int32 {hw:entity-mib}?
+         +--ro node-name?             string
+         +--ro node-location?         string
+
+
+
+
+
+
+2.1.1.6. YANG Module +
+
+
+
+2.1.1.6. ヤンモジュール +
+
+
+
+
+ 
+<CODE BEGINS> file "ietf-tpm-remote-attestation@2024-12-05.yang"
+module ietf-tpm-remote-attestation {
+  yang-version 1.1;
+  namespace "urn:ietf:params:xml:ns:yang"
+          + ":ietf-tpm-remote-attestation";
+  prefix tpm;
+
+  import ietf-yang-types {
+    prefix yang;
+  }
+  import ietf-hardware {
+    prefix hw;
+  }
+  import ietf-keystore {
+    prefix ks;
+  }
+  import ietf-tcg-algs {
+    prefix taa;
+  }
+
+  organization
+    "IETF RATS (Remote ATtestation procedureS) Working Group";
+  contact
+    "WG Web  : <https://datatracker.ietf.org/wg/rats/>
+     WG List : <mailto:rats@ietf.org>
+     Author  : Eric Voit <evoit@cisco.com>
+     Author  : Henk Birkholz <henk.birkholz@ietf.contact>
+     Author  : Michael Eckel <michael.eckel@sit.fraunhofer.de>
+     Author  : Shwetha Bhandari <shwetha.bhandari@thoughtspot.com>
+     Author  : Bill Sulzen <bsulzen@cisco.com>
+     Author  : Liang Xia (Frank) <frank.xialiang@huawei.com>
+     Author  : Tom Laffey <tom.laffey@hpe.com>
+     Author  : Guy C. Fedorkow <gfedorkow@juniper.net>";
+  description
+    "A YANG module to enable remote attestation procedures based
+     on TPM 1.2 and TPM 2.0 using a challenge-response
+     interaction model and the Quote primitive operations defined
+     by TPM 1.2 and TPM 2.0.
+
+     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 (RFC 2119) (RFC 8174) when, and only when,
+     they appear in all capitals, as shown here.
+
+     Copyright (c) 2024 IETF Trust and the persons identified as
+     authors of the code.  All rights reserved.
+
+     Redistribution and use in source and binary forms, with or
+     without modification, is permitted pursuant to, and subject to
+     the license terms contained in, the Revised BSD License set
+     forth in Section 4.c of the IETF Trust's Legal Provisions
+     Relating to IETF Documents
+     (https://trustee.ietf.org/license-info).
+
+     This version of this YANG module is part of RFC 9684; see the
+     RFC itself for full legal notices.";
+
+  revision 2024-12-05 {
+    description
+      "Initial version";
+    reference
+      "RFC 9684: A YANG Data Model for Challenge-Response-Based
+       Remote Attestation (CHARRA) Procedures Using Trusted Platform
+       Modules (TPMs)";
+  }
+
+  /*****************/
+  /*   Features    */
+  /*****************/
+
+  feature mtpm {
+    description
+      "The device supports the remote attestation of multiple
+       TPM-based cryptoprocessors.";
+  }
+
+  feature bios {
+    description
+      "The device supports the BIOS logs.";
+    reference
+      "BIOS-Log:
+       TCG PC Client Platform Firmware Profile Specification,
+       https://trustedcomputinggroup.org/wp-content/uploads/
+       TCG-PC-Client-Platform-Firmware-Profile-Version-1.06-
+       Revision-52_pub-2.pdf, Section 10.4.5.2";
+  }
+
+  feature ima {
+    description
+      "The device supports Integrity Measurement Architecture logs.
+       Many variants of IMA logs exist in the deployment.  Each
+       encodes the log entry contents as the specific measurements
+       that get hashed into a PCRs as Evidence.  See the reference
+       below for one example of such an encoding.";
+    reference
+      "CEL:
+       Canonical Event Log Format,
+       https://www.trustedcomputinggroup.org/wp-content/uploads/
+       TCG_IWG_CEL_v1_r0p41_pub.pdf, Section 5.1.6";
+  }
+
+  feature netequip_boot {
+    description
+      "The device supports the netequip_boot logs.";
+    reference
+      "RFC 9684: A YANG Data Model for Challenge-Response-Based
+       Remote Attestation (CHARRA) Procedures Using Trusted Platform
+       Modules (TPMs), Appendix B";
+  }
+
+  /*****************/
+  /*   Typedefs    */
+  /*****************/
+
+  typedef pcr {
+    type uint8 {
+      range "0..31";
+    }
+    description
+      "Valid index number for a PCR.  A PCR index compliant with
+       TPM 2.0 extends from 0-31.  At this time, a typical TPM would
+       have no more than 32 PCRs.";
+  }
+
+  typedef compute-node-ref {
+    type leafref {
+      path "/tpm:rats-support-structures/tpm:compute-nodes"
+         + "/tpm:compute-node/tpm:node-id";
+    }
+    description
+      "This type is used to reference a hardware node.  Note that an
+       implementer might include an alternative leafref pointing to a
+       different YANG module node specifying hardware structures.";
+  }
+
+  typedef certificate-name-ref {
+    type leafref {
+      path "/tpm:rats-support-structures/tpm:tpms/tpm:tpm"
+         + "/tpm:certificates/tpm:certificate/tpm:name";
+    }
+    description
+      "A type that allows identification of a TPM-based
+       certificate.";
+  }
+
+  /******************/
+  /*   Identities   */
+  /******************/
+
+  identity attested_event_log_type {
+    description
+      "Base identity allowing categorization of the reasons why an
+       attested measurement has been taken on an Attester.";
+  }
+
+  identity ima {
+    base attested_event_log_type;
+    description
+      "An event type recorded in IMA.";
+  }
+
+  identity bios {
+    base attested_event_log_type;
+    description
+      "An event type associated with BIOS/UEFI.";
+  }
+
+  identity netequip_boot {
+    base attested_event_log_type;
+    description
+      "An event type associated with Network Equipment Boot.";
+  }
+
+  /*****************/
+  /*   Groupings   */
+  /*****************/
+
+  grouping tpm20-hash-algo {
+    description
+      "The cryptographic algorithm used to hash the PCRs compliant
+       with TPM 2.0.  This must be from the list of platform-
+       supported options.";
+    leaf tpm20-hash-algo {
+      type identityref {
+        base taa:hash;
+      }
+      must '. = /tpm:rats-support-structures'
+         + '/tpm:attester-supported-algos/tpm:tpm20-hash' {
+        error-message "This platform does not support "
+                    + "tpm20-hash-algo";
+      }
+      description
+        "The hash scheme that is used to hash a PCR compliant with
+         TPM 2.0.  This must be one of those supported by a platform.
+         Where this object does not appear, the default value of
+         'taa:TPM_ALG_SHA256' will apply.";
+    }
+  }
+
+  grouping tpm12-hash-algo {
+    description
+      "The cryptographic algorithm used to hash the PCRs compliant
+       with TPM 1.2.";
+    leaf tpm12-hash-algo {
+      type identityref {
+        base taa:hash;
+      }
+      must '. = /tpm:rats-support-structures'
+         + '/tpm:attester-supported-algos/tpm:tpm12-hash' {
+        error-message "This platform does not support "
+                    + "tpm12-hash-algo";
+      }
+      description
+        "The hash scheme that is used to hash a PCR compliant with
+         TPM 1.2.  This MUST be one of those supported by a platform.
+         Where this object does not appear, the default value of
+         'taa:TPM_ALG_SHA1' will apply.";
+    }
+  }
+
+  grouping nonce {
+    description
+      "A random number intended to guarantee freshness and for use
+       as part of a replay-detection mechanism.";
+    leaf nonce-value {
+      type binary;
+      mandatory true;
+      description
+        "A cryptographically generated random number that should
+         not be predictable prior to its issuance from a random
+         number generation function.  The random number MUST be
+         derived from an entropy source external to the Attester.
+
+         Note that a nonce sent into a TPM will typically be 160 or
+         256 binary digits long.  (This is 20 or 32 bytes.)  So if
+         fewer binary digits are sent, this nonce object will be
+         padded with leading zeros within Quotes returned from the
+         TPM.  Additionally, if more bytes are sent, the nonce will
+         be trimmed to the most significant binary digits.";
+    }
+  }
+
+  grouping tpm12-pcr-selection {
+    description
+      "A Verifier can request one or more PCR values using its
+       individually created Attestation Key Certificate (AC).
+       The corresponding selection filter is represented in this
+       grouping.";
+    leaf-list pcr-index {
+      type pcr;
+      description
+        "The numbers/indexes of the PCRs.  In addition, any selection
+         of PCRs MUST verify that the set of PCRs requested are a
+         subset of the set of PCRs exposed in the leaf-list
+         /tpm:rats-support-structures
+         /tpm:tpms/tpm:tpm[name=current()]/tpm:tpm12-pcrs";
+    }
+  }
+
+  grouping tpm20-pcr-selection {
+    description
+      "A Verifier can acquire one or more PCR values, which are
+       hashed together in a TPM2B_DIGEST coming from the TPM2.
+       The selection list of desired PCRs and the hash algorithm
+       is represented in this grouping.";
+    list tpm20-pcr-selection {
+      unique "tpm20-hash-algo";
+      description
+        "Specifies the list of PCRs and hash algorithms that can be
+         returned within a TPM2B_DIGEST.";
+      reference
+        "TPM2.0-Structures:
+         Trusted Platform Module Library Part 2:  Structures,
+         Revision 01.83, https://trustedcomputinggroup.org/
+         wp-content/uploads/TPM-2.0-1.83-Part-2-Structures.pdf,
+         Section 10.9.7";
+      uses tpm20-hash-algo;
+      leaf-list pcr-index {
+        type pcr;
+        description
+          "The numbers of the PCRs that are being tracked
+           with a hash based on the tpm20-hash-algo.  In addition,
+           any selection of PCRs MUST verify that the set of PCRs
+           requested are a subset of the set of selected PCR indexes
+           available for that specific TPM.";
+      }
+    }
+  }
+
+  grouping certificate-name-ref {
+    description
+      "Identifies a certificate in a keystore.";
+    leaf certificate-name {
+      type certificate-name-ref;
+      mandatory true;
+      description
+        "Identifies a certificate in a keystore.";
+    }
+  }
+
+  grouping tpm-name {
+    description
+      "A unique TPM on a device.";
+    leaf name {
+      type string;
+      description
+        "Unique system-generated name for a TPM on a device.";
+    }
+  }
+
+  grouping node-uptime {
+    description
+      "Uptime in seconds of the node.";
+    leaf up-time {
+      type uint32;
+      description
+        "Uptime in seconds of this node reporting its data.";
+    }
+  }
+
+  grouping tpm12-attestation {
+    description
+      "Contains an instance of cryptoprocessor measurements signed
+       according to TPM 1.2.  It is supplemented by unsigned
+       Attester information.";
+    uses node-uptime;
+    leaf pcr-data {
+      type binary;
+      description
+        "The value created and signed for the quote
+         (type TPM_PCR_INFO_SHORT), i.e., the 'pcrData' part of
+          a TPM1.2 Quote2 operation result.";
+      reference
+        "TPM1.2-Commands:
+         TPM Main Part 3 Commands, Rev116,
+         https://trustedcomputinggroup.org/wp-content/uploads
+         /TPM-Main-Part-3-Commands_v1.2_rev116_01032011.pdf,
+         Section 16.5";
+    }
+    leaf version-info {
+      type binary;
+      description
+        "The version info (type TPM_CAP_VERSION_INFO),
+         i.e., the 'versionInfo' part of a TPM1.2 Quote2
+         operation result.";
+      reference
+        "TPM1.2-Commands:
+         TPM Main Part 3 Commands, Rev116,
+         https://trustedcomputinggroup.org/wp-content/uploads
+         /TPM-Main-Part-3-Commands_v1.2_rev116_01032011.pdf,
+         Section 16.5";
+    }
+    leaf sig {
+      type binary;
+      description
+        "The signature generated across the signed data,
+         i.e., the 'sig' part of a TPM1.2 Quote2 operation
+         result.";
+      reference
+        "TPM1.2-Commands:
+         TPM Main Part 3 Commands, Rev116,
+         https://trustedcomputinggroup.org/wp-content/uploads
+         /TPM-Main-Part-3-Commands_v1.2_rev116_01032011.pdf,
+         Section 16.5";
+    }
+  }
+
+  grouping tpm20-attestation {
+    description
+      "Contains an instance of cryptoprocessor measurements signed
+       according to TPM 2.0.  It is supplemented by unsigned
+       Attester information.";
+    leaf quote-data {
+      type binary;
+      mandatory true;
+      description
+        "A hash of the latest PCR values (and the hash algorithm
+         used) that have been returned from an Attester for the
+         selected PCRs and hash algorithms.";
+      reference
+        "TPM2.0-Structures:
+         Trusted Platform Module Library Part 2:  Structures,
+         Revision 01.83, https://trustedcomputinggroup.org/
+         wp-content/uploads/TPM-2.0-1.83-Part-2-Structures.pdf,
+         Section 10.12.1";
+    }
+    leaf quote-signature {
+      type binary;
+      description
+        "Quote signature returned by TPM Quote.  The signature was
+         generated using the key associated with the
+         certificate 'name'.";
+      reference
+        "TPM2.0-Structures:
+         Trusted Platform Module Library Part 2:  Structures,
+         Revision 01.83, https://trustedcomputinggroup.org/
+         wp-content/uploads/TPM-2.0-1.83-Part-2-Structures.pdf,
+         Section 11.2.1";
+    }
+    uses node-uptime;
+    list unsigned-pcr-values {
+      description
+        "PCR values in each PCR bank.  This might appear redundant
+         with the TPM2B_DIGEST, but that digest is calculated across
+         multiple PCRs.  Having to verify across multiple PCRs does
+         not necessarily make it easy for a Verifier to appraise just
+         the minimum set of PCR information that has changed since
+         the last received TPM2B_DIGEST.  Put another way, why should
+         a Verifier reconstruct the proper value of all PCR Quotes
+         when only a single PCR has changed?
+         To help this happen, if the Attester does know specific PCR
+         values, the Attester can provide these individual values via
+         'unsigned-pcr-values'.  By comparing this information to
+         what has previously been validated, it is possible for a
+         Verifier to confirm the Attester's signature while
+         eliminating significant processing.  Note that there should
+         never be a result where an unsigned PCR value differs from
+         what may be reconstructed from within the PCR quote and
+         the event logs.
+         If there is a difference, a signed result that has been
+         verified from retrieved logs is considered definitive.";
+      uses tpm20-hash-algo;
+      list pcr-values {
+        key "pcr-index";
+        description
+          "List of one PCR bank.";
+        leaf pcr-index {
+          type pcr;
+          description
+            "PCR index number.";
+        }
+        leaf pcr-value {
+          type binary;
+          description
+            "PCR value.";
+          reference
+            "TPM2.0-Structures:
+             Trusted Platform Module Library Part 2:  Structures,
+             Revision 01.83, https://trustedcomputinggroup.org/
+             wp-content/uploads/TPM-2.0-1.83-Part-2-Structures.pdf,
+             Section 10.9.7";
+        }
+      }
+    }
+  }
+
+  grouping log-identifier {
+    description
+      "Identifier for type of log to be retrieved.";
+    leaf log-type {
+      type identityref {
+        base attested_event_log_type;
+      }
+      mandatory true;
+      description
+        "The corresponding identity of the measurement log type.";
+    }
+  }
+
+  grouping boot-event-log {
+    description
+      "Defines a specific instance of an event log entry
+       and corresponding to the information used to
+       extend the PCR.";
+    leaf event-number {
+      type uint32;
+      description
+        "Unique event number of this event, which monotonically
+         increases within a given event log.  The maximum event
+         number should not be reached, nor is wrapping back to
+         an earlier number supported.";
+    }
+    leaf event-type {
+      type uint32;
+      description
+        "BIOS log event type.";
+      reference
+        "BIOS-Log:
+         TCG PC Client Platform Firmware Profile Specification,
+         https://trustedcomputinggroup.org/wp-content/uploads/
+         TCG-PC-Client-Platform-Firmware-Profile-Version-1.06-
+         Revision-52_pub-2.pdf, Section 10.4.1";
+    }
+    leaf pcr-index {
+      type pcr;
+      description
+        "Defines the PCR index that this event extended.";
+    }
+    list digest-list {
+      description
+        "Hash of event data.";
+      leaf hash-algo {
+        type identityref {
+          base taa:hash;
+        }
+        description
+          "The hash scheme that is used to compress the event data in
+           each of the leaf-list digest items.";
+      }
+      leaf-list digest {
+        type binary;
+        description
+          "The hash of the event data using the algorithm of the
+           'hash-algo' against 'event data'.";
+      }
+    }
+    leaf event-size {
+      type uint32;
+      description
+        "Size of the event data.";
+    }
+    leaf-list event-data {
+      type binary;
+      description
+        "The event data.  This is a binary structure
+         of size 'event-size'. For more on what
+         might be recorded within this object
+         see BIOS-Log, Section 10, which details
+         viable events that might be recorded.";
+      reference
+        "BIOS-Log:
+         TCG PC Client Platform Firmware Profile Specification,
+         https://trustedcomputinggroup.org/wp-content/uploads/
+         TCG-PC-Client-Platform-Firmware-Profile-Version-1.06-
+         Revision-52_pub-2.pdf, Section 10";
+    }
+  }
+
+  grouping bios-event-log {
+    description
+      "Measurement log created by the BIOS/UEFI.";
+    list bios-event-entry {
+      key "event-number";
+      description
+        "Ordered list of the TCG-described event log
+         that extended the PCRs in the order they
+         were logged.";
+      uses boot-event-log;
+    }
+  }
+
+  grouping ima-event {
+    description
+      "Defines a hash log extend event for IMA measurements.";
+    reference
+      "CEL:
+       Canonical Event Log Format,
+       https://www.trustedcomputinggroup.org/wp-content/uploads/
+       TCG_IWG_CEL_v1_r0p41_pub.pdf, Section 4.3";
+    leaf event-number {
+      type uint64;
+      description
+        "Unique event number of this event, which monotonically
+         increases.  The maximum event number should not be
+         reached, nor is wrapping back to an earlier number
+         supported.";
+    }
+    leaf ima-template {
+      type string;
+      description
+        "Name of the template used for event logs,
+         e.g., ima, ima-ng, ima-sig.";
+    }
+    leaf filename-hint {
+      type string;
+      description
+        "File name (including the path) that was measured.";
+    }
+    leaf filedata-hash {
+      type binary;
+      description
+        "Hash of filedata as updated based upon the
+         filedata-hash-algorithm.";
+    }
+    leaf filedata-hash-algorithm {
+      type string;
+      description
+        "Algorithm used for filedata-hash.";
+    }
+    leaf template-hash-algorithm {
+      type string;
+      description
+        "Algorithm used for template-hash.";
+    }
+    leaf template-hash {
+      type binary;
+      description
+        "hash(filedata-hash, filename-hint)";
+    }
+    leaf pcr-index {
+      type pcr;
+      description
+        "Defines the PCR index that this event extended.";
+    }
+    leaf signature {
+      type binary;
+      description
+        "Digital file signature that provides a
+         fingerprint for the file being measured.";
+    }
+  }
+
+  grouping ima-event-log {
+    description
+      "Measurement log created by IMA.";
+    list ima-event-entry {
+      key "event-number";
+      description
+        "Ordered list of IMA event logs by event-number.";
+      uses ima-event;
+    }
+  }
+
+  grouping network-equipment-boot-event-log {
+    description
+      "Measurement log created by Network Equipment Boot.  The
+       Network Equipment Boot format is identical to the IMA
+       format.  In contrast to the IMA log, the Network Equipment
+       Boot log includes every measurable event from an Attester,
+       including the boot stages of BIOS, Bootloader, etc. In
+       essence, the scope of events represented in this format
+       combines the scope of BIOS events and IMA events.";
+    list boot-event-entry {
+      key "event-number";
+      description
+        "Ordered list of Network Equipment Boot event logs
+         by event-number, using the IMA event format.";
+      uses ima-event;
+    }
+  }
+
+  grouping event-logs {
+    description
+      "A selector for the log and its type.";
+    choice attested_event_log_type {
+      mandatory true;
+      description
+        "Event log type determines the event log's content.";
+      case bios {
+        if-feature "bios";
+        description
+          "BIOS/UEFI event logs.";
+        container bios-event-logs {
+          description
+            "BIOS/UEFI event logs.";
+          uses bios-event-log;
+        }
+      }
+      case ima {
+        if-feature "ima";
+        description
+          "IMA event logs.";
+        container ima-event-logs {
+          description
+            "IMA event logs.";
+          uses ima-event-log;
+        }
+      }
+      case netequip_boot {
+        if-feature "netequip_boot";
+        description
+          "Network Equipment Boot event logs.";
+        container boot-event-logs {
+          description
+            "Network Equipment Boot event logs.";
+          uses network-equipment-boot-event-log;
+        }
+      }
+    }
+  }
+
+  /**********************/
+  /*   RPC operations   */
+  /**********************/
+
+  rpc tpm12-challenge-response-attestation {
+    if-feature "taa:tpm12";
+    description
+      "This RPC accepts the input for TSS TPM 1.2 commands made to
+       the attesting device.";
+    input {
+      container tpm12-attestation-challenge {
+        description
+          "This container includes every information element defined
+           in the reference challenge-response interaction model for
+           remote attestation.  Corresponding values are based on
+           TPM 1.2 structure definitions";
+        uses tpm12-pcr-selection;
+        uses nonce;
+        leaf-list certificate-name {
+          if-feature "tpm:mtpm";
+          type certificate-name-ref;
+          must "/tpm:rats-support-structures/tpm:tpms"
+             + "/tpm:tpm[tpm:firmware-version='taa:tpm12']"
+             + "/tpm:certificates/"
+             + "/tpm:certificate[name=current()]" {
+            error-message "Not an available TPM1.2 AIK certificate.";
+          }
+          description
+            "When populated, the RPC will only get a Quote for the
+             TPMs associated with these certificate(s).";
+        }
+      }
+    }
+    output {
+      list tpm12-attestation-response {
+        unique "certificate-name";
+        description
+          "The binary output of TPM 1.2 TPM_Quote/TPM_Quote2,
+           including the PCR selection and other associated
+           attestation evidence metadata.";
+        uses certificate-name-ref {
+          description
+            "Certificate associated with this tpm12-attestation.";
+        }
+        uses tpm12-attestation;
+      }
+    }
+  }
+
+  rpc tpm20-challenge-response-attestation {
+    if-feature "taa:tpm20";
+    description
+      "This RPC accepts the input for TSS TPM 2.0 commands of the
+       managed device.  Composite devices may contain several TPMs;
+       /hardware/component/physical-index from the hardware
+       management YANG module is used to refer to dedicated TPMs in
+       composite devices; however, devices without TPMs are not
+       covered.";
+    input {
+      container tpm20-attestation-challenge {
+        description
+          "This container includes every information element defined
+           in the reference challenge-response interaction model for
+           remote attestation.  Corresponding values are based on
+           TPM 2.0 structure definitions.";
+        uses nonce;
+        uses tpm20-pcr-selection;
+        leaf-list certificate-name {
+          if-feature "tpm:mtpm";
+          type certificate-name-ref;
+          must "/tpm:rats-support-structures/tpm:tpms"
+             + "/tpm:tpm[tpm:firmware-version='taa:tpm20']"
+             + "/tpm:certificates/"
+             + "/tpm:certificate[name=current()]" {
+            error-message "Not an available TPM2.0 AIK certificate.";
+          }
+          description
+            "When populated, the RPC will only get a Quote for the
+             TPMs associated with the certificates.";
+        }
+      }
+    }
+    output {
+      list tpm20-attestation-response {
+        unique "certificate-name";
+        description
+          "The binary output of TPM2_Quote from one TPM of the
+           node which is identified by node-id:  an attestation
+           structure (TPMS_ATTEST), including a length, and a
+           signature (TPMT_SIGNATURE) over that structure.";
+        reference
+          "TPM2.0-Structures:
+           Trusted Platform Module Library Part 2:  Structures,
+           Revision 01.83, https://trustedcomputinggroup.org/
+           wp-content/uploads/TPM-2.0-1.83-Part-2-Structures.pdf,
+           Section 10.12.12";
+        uses certificate-name-ref {
+          description
+            "Certificate associated with this tpm20-attestation.";
+        }
+        uses tpm20-attestation;
+      }
+    }
+  }
+
+  rpc log-retrieval {
+    description
+      "Log entries are identified either via indices or by providing
+       the last line received.  The number of lines returned can be
+       limited.  The type of log is a choice that can be augmented.";
+    input {
+      uses log-identifier;
+      list log-selector {
+        description
+          "Only log entries that meet all of the provided selection
+           criteria are to be returned by the RPC output.";
+        leaf-list name {
+          type string;
+          description
+            "Name of one or more unique TPMs on a device.  If this
+             object exists, a selection should pull only the objects
+             related to these TPM(s).  If it does not exist, all
+             qualifying TPMs that are 'hardware-based' equals true
+             on the device are selected.  When this selection
+             criteria is provided, it will be considered as a logical
+             AND with any other selection criteria provided.";
+        }
+        choice index-type {
+          description
+            "Last log entry received, log index number, or
+             timestamp.";
+          case last-entry {
+            description
+              "The last entry of the log already retrieved.";
+            leaf last-entry-value {
+              type binary;
+              description
+                "Content of a log event that matches 1:1 with a
+                 unique event record contained within the log.  Log
+                 entries after this will be passed to the
+                 requester.  Note: if log entry values are not
+                 unique, this MUST return an error.";
+            }
+          }
+          case index {
+            description
+              "Numeric index of the last log entry retrieved, or
+               zero.";
+            leaf last-index-number {
+              type uint64;
+              description
+                "The last numeric index number of a log entry.
+                 Zero means to start at the beginning of the log.
+                 Entries after this will be passed to the
+                 requester.";
+            }
+          }
+          case timestamp {
+            leaf timestamp {
+              type yang:date-and-time;
+              description
+                "Timestamp from which to start the extraction.  The
+                 next log entry after this timestamp is to
+                 be sent.";
+            }
+            description
+              "Timestamp from which to start the extraction.";
+          }
+        }
+        leaf log-entry-quantity {
+          type uint16;
+          description
+            "The number of log entries to be returned. If omitted, it
+             means all of them.";
+        }
+      }
+    }
+    output {
+      container system-event-logs {
+        description
+          "The requested data of the measurement event logs.";
+        list node-data {
+          unique "name";
+          description
+            "Event logs of a node in a distributed system
+             identified by the node name.";
+          uses tpm-name;
+          uses node-uptime;
+          container log-result {
+            description
+              "The requested entries of the corresponding log.";
+            uses event-logs;
+          }
+        }
+      }
+    }
+  }
+
+  /****************************************/
+  /*   Config and Oper accessible nodes   */
+  /****************************************/
+
+  container rats-support-structures {
+    description
+      "The datastore definition enabling Verifiers or Relying
+       Parties to discover the information necessary to use the
+       remote attestation RPCs appropriately.";
+    container compute-nodes {
+      if-feature "tpm:mtpm";
+      description
+        "Holds the set of device subsystems/components in this
+         composite device that support TPM operations.";
+      list compute-node {
+        key "node-id";
+        unique "node-name";
+        config false;
+        min-elements 2;
+        description
+          "A component within this composite device that
+           supports TPM operations.";
+        leaf node-id {
+          type string;
+          description
+            "ID of the compute node, such as Board Serial Number.";
+        }
+        leaf node-physical-index {
+          if-feature "hw:entity-mib";
+          type int32 {
+            range "1..2147483647";
+          }
+          config false;
+          description
+            "The entPhysicalIndex for the compute node.";
+          reference
+            "RFC 6933: Entity MIB (Version 4) - entPhysicalIndex";
+        }
+        leaf node-name {
+          type string;
+          description
+            "Name of the compute node.";
+        }
+        leaf node-location {
+          type string;
+          description
+            "Location of the compute node, such as slot number.";
+        }
+      }
+    }
+    container tpms {
+      description
+        "Holds the set of TPMs within an Attester.";
+      list tpm {
+        key "name";
+        unique "path";
+        description
+          "A list of TPMs in this composite device that RATS
+           can be conducted with.";
+        uses tpm-name;
+        leaf hardware-based {
+          type boolean;
+          config false;
+          mandatory true;
+          description
+            "System-generated indication of whether this is a
+             hardware-based TPM.";
+        }
+        leaf physical-index {
+          if-feature "hw:entity-mib";
+          type int32 {
+            range "1..2147483647";
+          }
+          config false;
+          description
+            "The entPhysicalIndex for the TPM.";
+          reference
+            "RFC 6933: Entity MIB (Version 4) - entPhysicalIndex";
+        }
+        leaf path {
+          type string;
+          config false;
+          description
+            "Device path to a unique TPM on a device.  This can
+             change across reboots.";
+        }
+        leaf compute-node {
+          if-feature "tpm:mtpm";
+          type compute-node-ref;
+          config false;
+          mandatory true;
+          description
+            "Indicates the compute node measured by this TPM.";
+        }
+        leaf manufacturer {
+          type string;
+          config false;
+          description
+            "TPM manufacturer name.";
+        }
+        leaf firmware-version {
+          type identityref {
+            base taa:cryptoprocessor;
+          }
+          mandatory true;
+          description
+            "Identifies the cryptoprocessor API set supported.  This
+             is automatically configured by the device and should not
+             be changed.";
+        }
+        uses tpm12-hash-algo {
+          when "derived-from-or-self(firmware-version, 'taa:tpm12')";
+          if-feature "taa:tpm12";
+          refine "tpm12-hash-algo" {
+            description
+              "The hash algorithm overwrites the default used for
+               PCRs on this TPM1.2-compliant cryptoprocessor.";
+          }
+        }
+        leaf-list tpm12-pcrs {
+          when "derived-from-or-self(../firmware-version, "
+             + "'taa:tpm12')";
+          if-feature "taa:tpm12";
+          type pcr;
+          description
+            "The PCRs that may be extracted from this TPM1.2-
+             compliant cryptoprocessor.";
+        }
+        list tpm20-pcr-bank {
+          when "derived-from-or-self(../firmware-version, "
+             + "'taa:tpm20')";
+          if-feature "taa:tpm20";
+          key "tpm20-hash-algo";
+          description
+            "Specifies the list of PCRs that may be extracted for
+             a specific hash algorithm on this TPM2-compliant
+             cryptoprocessor.  A bank is a set of PCRs that are
+             extended using a particular hash algorithm.";
+          reference
+            "TPM2.0-Structures:
+             Trusted Platform Module Library Part 2:  Structures,
+             Revision 01.83, https://trustedcomputinggroup.org/
+             wp-content/uploads/TPM-2.0-1.83-Part-2-Structures.pdf,
+             Section 10.9.7";
+          leaf tpm20-hash-algo {
+            type identityref {
+              base taa:hash;
+            }
+            must '/tpm:rats-support-structures'
+               + '/tpm:attester-supported-algos'
+               + '/tpm:tpm20-hash' {
+              error-message "This platform does not support "
+                          + "tpm20-hash-algo";
+            }
+            description
+              "The hash scheme actively being used to hash
+               one or more TPM2.0 PCRs.";
+          }
+          leaf-list pcr-index {
+            type tpm:pcr;
+            description
+              "Defines which TPM2.0 PCRs are available to be
+               extracted.";
+          }
+        }
+        leaf status {
+          type enumeration {
+            enum operational {
+              value 0;
+              description
+                "The TPM currently is running normally and
+                 is ready to accept and process TPM quotes.";
+              reference
+                "TPM2.0-Arch: Trusted Platform Module Library
+                 Part 1:  Architecture,
+                 https://trustedcomputinggroup.org/wp-content/
+                 uploads/TPM-2.0-1.83-Part-1-Architecture.pdf,
+                 Section 12";
+            }
+            enum non-operational {
+              value 1;
+              description
+                "TPM is in a state such as startup or shutdown, which
+                 precludes the processing of TPM quotes.";
+            }
+          }
+          config false;
+          mandatory true;
+          description
+            "TPM chip self-test status.";
+        }
+        container certificates {
+          description
+            "The TPM's certificates, including EK Certificates
+             and Attestation Key Certificates.";
+          list certificate {
+            key "name";
+            description
+              "Three types of certificates can be accessed via
+               this statement, including Initial Attestation
+               Key Certificate, Local Attestation Key Certificate, or
+               Endorsement Key Certificate.";
+            leaf name {
+              type string;
+              description
+                "An arbitrary name uniquely identifying a certificate
+                 associated with a key within a TPM.";
+            }
+            leaf keystore-ref {
+              if-feature "ks:central-keystore-supported";
+              if-feature "ks:asymmetric-keys";
+              type leafref {
+                path "/ks:keystore/ks:asymmetric-keys"
+                   + "/ks:asymmetric-key/ks:name";
+              }
+              description
+                "A reference to a specific certificate of an
+                 asymmetric key in the keystore.";
+            }
+            leaf type {
+              type enumeration {
+                enum endorsement-certificate {
+                  value 0;
+                  description
+                    "Endorsement Key (EK) Certificate type.";
+                  reference
+                    "TPM2.0-Key:
+                     TPM 2.0 Keys for Device Identity and Attestation
+                     https://trustedcomputinggroup.org/wp-content/
+                     uploads/TPM-2p0-Keys-for-Device-Identity-
+                     and-Attestation_v1_r12_pub10082021.pdf,
+                     Section 3.11";
+                }
+                enum initial-attestation-certificate {
+                  value 1;
+                  description
+                    "Initial Attestation Key (IAK) Certificate
+                     type.";
+                  reference
+                    "TPM2.0-Key:
+                     TPM 2.0 Keys for Device Identity and Attestation
+                     https://trustedcomputinggroup.org/wp-content/
+                     uploads/TPM-2p0-Keys-for-Device-Identity-
+                     and-Attestation_v1_r12_pub10082021.pdf,
+                     Section 3.2";
+                }
+                enum local-attestation-certificate {
+                  value 2;
+                  description
+                    "Local Attestation Key (LAK) Certificate type.";
+                  reference
+                    "TPM2.0-Key:
+                     TPM 2.0 Keys for Device Identity and Attestation
+                     https://trustedcomputinggroup.org/wp-content/
+                     uploads/TPM-2p0-Keys-for-Device-Identity-
+                     and-Attestation_v1_r12_pub10082021.pdf,
+                     Section 3.2";
+                }
+              }
+              description
+                "Function supported by this certificate from within
+                 the TPM.";
+            }
+          }
+        }
+      }
+    }
+    container attester-supported-algos {
+      description
+        "Identifies which TPM algorithms are available for use on an
+         attesting platform.";
+      leaf-list tpm12-asymmetric-signing {
+        when "../../tpm:tpms"
+           + "/tpm:tpm[tpm:firmware-version='taa:tpm12']";
+        if-feature "taa:tpm12";
+        type identityref {
+          base taa:asymmetric;
+        }
+        description
+          "Platform-supported TPM1.2 asymmetric algorithms.";
+      }
+      leaf-list tpm12-hash {
+        when "../../tpm:tpms"
+           + "/tpm:tpm[tpm:firmware-version='taa:tpm12']";
+        if-feature "taa:tpm12";
+        type identityref {
+          base taa:hash;
+        }
+        description
+          "Platform-supported TPM1.2 hash algorithms.";
+      }
+      leaf-list tpm20-asymmetric-signing {
+        when "../../tpm:tpms"
+           + "/tpm:tpm[tpm:firmware-version='taa:tpm20']";
+        if-feature "taa:tpm20";
+        type identityref {
+          base taa:asymmetric;
+        }
+        description
+          "Platform-supported TPM2.0 asymmetric algorithms.";
+      }
+      leaf-list tpm20-hash {
+        when "../../tpm:tpms"
+           + "/tpm:tpm[tpm:firmware-version='taa:tpm20']";
+        if-feature "taa:tpm20";
+        type identityref {
+          base taa:hash;
+        }
+        description
+          "Platform-supported TPM2.0 hash algorithms.";
+      }
+    }
+  }
+}
+<CODE ENDS>
+
+                               Figure 1
+
+
+
+
+
+
+2.1.2. ietf-tcg-algs +
+
+
+
+2.1.2. IETF-TCG-ALGS +
+
+
+
+
+

+This document has encoded the TCG Algorithm definitions of Table 3 of [TCG-Algos], revision 1.32. By including this full table as a separate YANG file within this document, it is possible for other YANG modules to leverage the contents of this module. Specific references to [TPM1.2-Structures], [TPM2.0], [RFC2104], [RFC8017], [RFC8032], [ISO-IEC-9797-1], [ISO-IEC-9797-2], [ISO-IEC-10116], [ISO-IEC-10118-3], [ISO-IEC-14888-3], [ISO-IEC-15946-1], [ISO-IEC-18033-3], [IEEE-Std-1363-2000], [IEEE-Std-1363a-2004], [NIST-FIPS-202], [NIST-SP800-38C], [NIST-SP800-38D], [NIST-SP800-38F], [NIST-SP800-56A], and [NIST-SP800-108] exist within the YANG module. +

+
+
+

+このドキュメントは、[TCG-Algos]の表3のTCGアルゴリズム定義をエンコードしました。このフルテーブルをこのドキュメント内に別のYangファイルとして含めることにより、他のYangモジュールがこのモジュールの内容を活用することができます。[TPM1.2構造]、[TPM2.0]、[RFC2104]、[RFC8017]、[RFC8032]、[ISO-IEC-9797-1]、[ISO-IEC-9797-2]、[ISO-IEC-9797-2]への特定の参照ISO-IEC-10116]、[ISO-IEC-10118-3]、[ISO-IEC-14888-3]、[ISO-IEC-15946-1]、[ISO-IEC-18033-3]、[IEEE-STD-1363-2000]、[IEEE-STD-1363A-2004]、[nist-fips-202]、[nist-sp800-38c]、[nist-sp800-38d]、[nist-sp800-38f]、[nist-sp800-56a]、および[nist-sp800-108]はヤンモジュール内に存在します。 +

+
+
+
+
+
+2.1.2.1. Features +
+
+
+
+2.1.2.1. 特徴 +
+
+
+
+
+

+There are two types of features supported: 'tpm12' and 'tpm20'. Support for either of these features indicates that a cryptoprocessor supporting the corresponding type of TCG TPM API is present on an Attester. Most commonly, only one type of cryptoprocessor will be available on an Attester. +

+
+
+

+サポートされている機能には、「TPM12」と「TPM20」という2種類の機能があります。これらの機能のいずれかをサポートすることは、対応するタイプのTCG TPM APIをサポートするクリプトプロセッサがastesterに存在することを示しています。最も一般的には、指標に利用できるようになります。 +

+
+
+
+
+
+2.1.2.2. Identities +
+
+
+
+2.1.2.2. アイデンティティ +
+
+
+
+
+

+There are three types of identities in this model: +

+
+
+

+このモデルには、3種類のアイデンティティがあります。 +

+
+
+
+
+

+1. Cryptographic functions supported by a TPM algorithm; these include 'asymmetric', 'symmetric', 'hash', 'signing', 'anonymous_signing', 'encryption_mode', 'method', and 'object_type'. The definitions of each of these are in Table 2 of [TCG-Algos]. +

+
+
+

+1. TPMアルゴリズムによってサポートされる暗号化関数。これらには、「非対称」、「対称」、「ハッシュ」、「署名」、「anonymous_singe」、「encryption_mode '、' method '、および' object_type 'が含まれます。これらのそれぞれの定義は、[TCG-Algos]の表2にあります。 +

+
+
+
+
+

+2. API specifications for TPM types: 'tpm12' and 'tpm20' +

+
+
+

+2. TPMタイプのAPI仕様：「TPM12」および「TPM20」 +

+
+
+
+
+

+3. Specific algorithm types: Each algorithm type defines which cryptographic functions may be supported, and on which type of API specification. It is not required that an implementation of a specific TPM will support all algorithm types. The contents of each specific algorithm mirrors the contents of Table 3 of [TCG-Algos]. +

+
+
+

+3. 特定のアルゴリズムタイプ：各アルゴリズムタイプは、どの暗号化関数がサポートされるか、どのタイプのAPI仕様を定義します。特定のTPMの実装がすべてのアルゴリズムタイプをサポートすることは必須ではありません。各特定のアルゴリズムの内容は、[TCG-Algos]の表3の内容を反映しています。 +

+
+
+
+
+
+2.1.2.3. YANG Module +
+
+
+
+2.1.2.3. ヤンモジュール +
+
+
+
+
+ 
+   module ietf-tcg-algs {
+     yang-version 1.1;
+     namespace "urn:ietf:params:xml:ns:yang:ietf-tcg-algs";
+     prefix taa;
+
+     organization
+       "IETF RATS (Remote ATtestation procedureS) Working Group";
+     contact
+       "WG Web:   <https://datatracker.ietf.org/wg/rats/>
+        WG List:  <mailto:rats@ietf.org>
+        Author:   Eric Voit <mailto:evoit@cisco.com>";
+     description
+       "This module defines identities for asymmetric algorithms.
+
+        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 (RFC 2119) (RFC 8174) when, and only when,
+        they appear in all capitals, as shown here.
+
+        Copyright (c) 2024 IETF Trust and the persons identified as
+        authors of the code.  All rights reserved.
+
+        Redistribution and use in source and binary forms, with or
+        without modification, is permitted pursuant to, and subject to
+        the license terms contained in, the Revised BSD License set
+        forth in Section 4.c of the IETF Trust's Legal Provisions
+        Relating to IETF Documents
+        (https://trustee.ietf.org/license-info).
+
+        This version of this YANG module is part of RFC 9684; see the
+        RFC itself for full legal notices.";
+
+     revision 2024-12-05 {
+       description
+         "Initial version";
+       reference
+         "RFC 9684: A YANG Data Model for Challenge-Response-Based
+          Remote Attestation (CHARRA) Procedures Using Trusted Platform
+          Modules (TPMs)";
+     }
+
+     /*****************/
+     /*   Features    */
+     /*****************/
+
+     feature tpm12 {
+       description
+         "This feature indicates algorithm support for the TPM 1.2 API
+          per Section 4.8 of TPM1.2-Structures.";
+       reference
+         "TPM1.2-Structures: TPM Main Part 2 TPM Structures,
+          https://trustedcomputinggroup.org/wp-content/uploads/
+          TPM-Main-Part-2-TPM-Structures_v1.2_rev116_01032011.pdf
+          TPM_ALGORITHM_ID values, Section 4.8";
+     }
+
+     feature tpm20 {
+       description
+         "This feature indicates algorithm support for the TPM 2.0 API
+          per Section 11.4 of Trusted Platform Module Library Part 1:
+          Architecture.";
+       reference
+         "TPM2.0-Arch: Trusted Platform Module Library Part 1:
+          Architecture, https://trustedcomputinggroup.org/wp-content/
+          uploads/TPM-2.0-1.83-Part-1-Architecture.pdf, Section 11.4";
+     }
+
+     /*****************/
+     /*  Identities   */
+     /*****************/
+
+     identity asymmetric {
+       description
+         "A TCG-recognized asymmetric algorithm with a public and
+          private key.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 2,
+          https://trustedcomputinggroup.org/resource/
+          tcg-algorithm-registry/TCG-_Algorithm_Registry_r1p32_pub";
+     }
+
+     identity symmetric {
+       description
+         "A TCG-recognized symmetric algorithm with only a private
+          key.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 2";
+     }
+
+     identity hash {
+       description
+         "A TCG-recognized hash algorithm that compresses input data to
+          a digest value or indicates a method that uses a hash.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 2";
+     }
+
+     identity signing {
+       description
+         "A TCG-recognized signing algorithm";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 2";
+     }
+
+     identity anonymous_signing {
+       description
+         "A TCG-recognized anonymous signing algorithm.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 2";
+     }
+
+     identity encryption_mode {
+       description
+         "A TCG-recognized encryption mode.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 2";
+     }
+
+     identity method {
+       description
+         "A TCG-recognized method such as a mask generation function.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 2";
+     }
+
+     identity object_type {
+       description
+         "A TCG-recognized object type.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 2";
+     }
+
+     identity cryptoprocessor {
+       description
+         "Base identity identifying a crytoprocessor.";
+     }
+
+     identity tpm12 {
+       if-feature "tpm12";
+       base cryptoprocessor;
+       description
+         "Supportable by a TPM 1.2.";
+       reference
+         "TPM1.2-Structures:
+          TPM Main Part 2 TPM Structures,
+          https://trustedcomputinggroup.org/wp-content/uploads/
+          TPM-Main-Part-2-TPM-Structures_v1.2_rev116_01032011.pdf
+          TPM_ALGORITHM_ID values, Section 4.8";
+     }
+
+     identity tpm20 {
+       if-feature "tpm20";
+       base cryptoprocessor;
+       description
+         "Supportable by a TPM 2.0";
+       reference
+         "TPM2.0-Structures:
+          Trusted Platform Module Library Part 2:  Structures,
+          Revision 01.83, https://trustedcomputinggroup.org/
+          wp-content/uploads/TPM-2.0-1.83-Part-2-Structures.pdf";
+     }
+
+     identity TPM_ALG_RSA {
+       if-feature "tpm12 or tpm20";
+       base tpm12;
+       base tpm20;
+       base asymmetric;
+       base object_type;
+       description
+         "RSA algorithm.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and
+          RFC 8017. ALG_ID: 0x0001";
+     }
+
+     identity TPM_ALG_TDES {
+       if-feature "tpm12";
+       base tpm12;
+       base symmetric;
+       description
+         "Block cipher with various key sizes (Triple Data Encryption
+          Algorithm, commonly called Triple Data Encryption Standard)
+          Note: Was banned in TPM 1.2, v94";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and
+          ISO/IEC 18033-3. ALG_ID: 0x0003";
+     }
+
+     identity TPM_ALG_SHA1 {
+       if-feature "tpm12 or tpm20";
+       base hash;
+       base tpm12;
+       base tpm20;
+       description
+         "SHA1 algorithm - Deprecated due to insufficient cryptographic
+          protection.  However, it is still useful for hash algorithms
+          where protection is not required.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry Rev1.34, Table 3, and
+          ISO/IEC 10118-3. ALG_ID: 0x0004";
+     }
+
+     identity TPM_ALG_HMAC {
+       if-feature "tpm12 or tpm20";
+       base tpm12;
+       base tpm20;
+       base hash;
+       base signing;
+       description
+         "Hash Message Authentication Code (HMAC) algorithm.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and
+          ISO/IEC 9797-2, and
+          RFC 2104. ALG_ID: 0x0005";
+     }
+
+     identity TPM_ALG_AES {
+       if-feature "tpm12";
+       base tpm12;
+       base symmetric;
+       description
+         "The AES algorithm with various key sizes.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and
+          ISO/IEC 18033-3. ALG_ID: 0x0006";
+     }
+
+     identity TPM_ALG_MGF1 {
+       if-feature "tpm20";
+       base tpm20;
+       base hash;
+       base method;
+       description
+         "Hash-based mask-generation function.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and
+          IEEE Std 1363-2000, and
+          IEEE Std 1363a-2004.
+          ALG_ID: 0x0007";
+     }
+
+     identity TPM_ALG_KEYEDHASH {
+       if-feature "tpm20";
+       base tpm20;
+       base hash;
+       base object_type;
+       description
+         "An encryption or signing algorithm using a keyed hash.  These
+          may use XOR for encryption or an HMAC for signing and may
+          also refer to a data object that is neither signing nor
+          encrypting.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3.
+          ALG_ID: 0x0008";
+     }
+
+     identity TPM_ALG_XOR {
+       if-feature "tpm12 or tpm20";
+       base tpm12;
+       base tpm20;
+       base hash;
+       base symmetric;
+       description
+         "The XOR encryption algorithm.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3.
+          ALG_ID: 0x000A";
+     }
+
+     identity TPM_ALG_SHA256 {
+       if-feature "tpm20";
+       base tpm20;
+       base hash;
+       description
+         "The SHA-256 algorithm.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and
+          ISO/IEC 10118-3. ALG_ID: 0x000B";
+     }
+
+     identity TPM_ALG_SHA384 {
+       if-feature "tpm20";
+       base tpm20;
+       base hash;
+       description
+         "The SHA-384 algorithm.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and
+          ISO/IEC 10118-3. ALG_ID: 0x000C";
+     }
+
+     identity TPM_ALG_SHA512 {
+       if-feature "tpm20";
+       base tpm20;
+       base hash;
+       description
+         "The SHA-512 algorithm.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and
+          ISO/IEC 10118-3. ALG_ID: 0x000D";
+     }
+
+     identity TPM_ALG_NULL {
+       if-feature "tpm20";
+       base tpm20;
+       description
+         "Null algorithm.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3.
+          ALG_ID: 0x0010";
+     }
+
+     identity TPM_ALG_SM3_256 {
+       if-feature "tpm20";
+       base tpm20;
+       base hash;
+       description
+         "The ShangMi 3 (SM3) hash algorithm.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and
+          ISO/IEC 10118-3:2018. ALG_ID: 0x0012";
+     }
+
+     identity TPM_ALG_SM4 {
+       if-feature "tpm20";
+       base tpm20;
+       base symmetric;
+       description
+         "ShangMi 4 (SM4) symmetric block cipher.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3.
+          ALG_ID: 0x0013";
+     }
+
+     identity TPM_ALG_RSASSA {
+       if-feature "tpm20";
+       base tpm20;
+       base asymmetric;
+       base signing;
+       description
+         "Signature algorithm defined in Section 8.2
+          (RSASSA-PKCS1-v1_5) of RFC 8017.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and
+          RFC 8017.  ALG_ID: 0x0014";
+     }
+
+     identity TPM_ALG_RSAES {
+       if-feature "tpm20";
+       base tpm20;
+       base asymmetric;
+       base encryption_mode;
+       description
+         "Signature algorithm defined in Section 7.2
+          (RSAES-PKCS1-v1_5) of RFC 8017.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and
+          RFC 8017. ALG_ID: 0x0015";
+     }
+
+     identity TPM_ALG_RSAPSS {
+       if-feature "tpm20";
+       base tpm20;
+       base asymmetric;
+       base signing;
+       description
+         "Padding algorithm defined in Section 8.1 (RSASSA-PSS)
+          of RFC 8017.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and
+          RFC 8017. ALG_ID: 0x0016";
+     }
+
+     identity TPM_ALG_OAEP {
+       if-feature "tpm20";
+       base tpm20;
+       base asymmetric;
+       base encryption_mode;
+       description
+         "Padding algorithm defined in Section 7.1 (RSAES-OAEP)
+          of RFC 8017.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and
+          RFC 8017. ALG_ID: 0x0017";
+     }
+
+     identity TPM_ALG_ECDSA {
+       if-feature "tpm20";
+       base tpm20;
+       base asymmetric;
+       base signing;
+       description
+         "Signature algorithm using elliptic curve cryptography (ECC).";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and
+          ISO/IEC 14888-3. ALG_ID: 0x0018";
+     }
+
+     identity TPM_ALG_ECDH {
+       if-feature "tpm20";
+       base tpm20;
+       base asymmetric;
+       base method;
+       description
+         "Secret sharing using ECC.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and
+          NIST SP800-56A. ALG_ID: 0x0019";
+     }
+
+     identity TPM_ALG_ECDAA {
+       if-feature "tpm20";
+       base tpm20;
+       base asymmetric;
+       base signing;
+       base anonymous_signing;
+       description
+         "Elliptic-curve-based, anonymous signing scheme.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and
+          TCG TPM 2.0 Library. ALG_ID: 0x001A";
+     }
+
+     identity TPM_ALG_SM2 {
+       if-feature "tpm20";
+       base tpm20;
+       base asymmetric;
+       base signing;
+       base encryption_mode;
+       base method;
+       description
+         "SM2 - depending on context, either an elliptic-curve based,
+          signature algorithm, an encryption scheme, or a key exchange
+          protocol.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3.
+          ALG_ID: 0x001B";
+     }
+
+     identity TPM_ALG_ECSCHNORR {
+       if-feature "tpm20";
+       base tpm20;
+       base asymmetric;
+       base signing;
+       description
+         "Elliptic-curve-based Schnorr signature.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3.
+          ALG_ID: 0x001C";
+     }
+
+     identity TPM_ALG_ECMQV {
+       if-feature "tpm20";
+       base tpm20;
+       base asymmetric;
+       base method;
+       description
+         "Two-phase elliptic-curve key.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and
+          NIST SP800-56A. ALG_ID: 0x001D";
+     }
+
+     identity TPM_ALG_KDF1_SP800_56A {
+       if-feature "tpm20";
+       base tpm20;
+       base hash;
+       base method;
+       description
+         "Concatenation key derivation function.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and
+          NIST SP800-56A  (approved alternative1) Section 5.8.1.
+          ALG_ID: 0x0020";
+     }
+
+     identity TPM_ALG_KDF2 {
+       if-feature "tpm20";
+       base tpm20;
+       base hash;
+       base method;
+       description
+         "Key derivation function.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and
+          IEEE 1363a-2004, KDF2, Section 13.2. ALG_ID: 0x0021";
+     }
+
+     identity TPM_ALG_KDF1_SP800_108 {
+       base TPM_ALG_KDF2;
+       description
+         "A key derivation method.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3 and
+          NIST SP800-108, Section 4.1, KDF. ALG_ID: 0x0022";
+     }
+
+     identity TPM_ALG_ECC {
+       if-feature "tpm20";
+       base tpm20;
+       base asymmetric;
+       base object_type;
+       description
+         "Prime field ECC.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and
+          ISO/IEC 15946-1. ALG_ID: 0x0023";
+     }
+
+     identity TPM_ALG_SYMCIPHER {
+       if-feature "tpm20";
+       base tpm20;
+       base symmetric;
+       base object_type;
+       description
+         "Object type for a symmetric block cipher.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and
+          TCG TPM 2.0 Library. ALG_ID: 0x0025";
+     }
+
+     identity TPM_ALG_CAMELLIA {
+       if-feature "tpm20";
+       base tpm20;
+       base symmetric;
+       description
+         "The Camellia algorithm.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and
+          ISO/IEC 18033-3. ALG_ID: 0x0026";
+     }
+
+     identity TPM_ALG_SHA3_256 {
+       if-feature "tpm20";
+       base tpm20;
+       base hash;
+       description
+         "ISO/IEC 10118-3 - the SHA-256 algorithm.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and
+          NIST FIPS 202. ALG_ID: 0x0027";
+     }
+
+     identity TPM_ALG_SHA3_384 {
+       if-feature "tpm20";
+       base tpm20;
+       base hash;
+       description
+         "The SHA-384 algorithm.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and
+          NIST FIPS 202. ALG_ID: 0x0028";
+     }
+
+     identity TPM_ALG_SHA3_512 {
+       if-feature "tpm20";
+       base tpm20;
+       base hash;
+       description
+         "The SHA-512 algorithm.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and
+          NIST FIPS 202. ALG_ID: 0x0029";
+     }
+
+     identity TPM_ALG_CMAC {
+       if-feature "tpm20";
+       base tpm20;
+       base symmetric;
+       base signing;
+       description
+         "Block Cipher-based Message Authentication Code (CMAC).";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and
+          ISO/IEC 9797-1:2011, Algorithm 5. ALG_ID: 0x003F";
+     }
+
+     identity TPM_ALG_CTR {
+       if-feature "tpm20";
+       base tpm20;
+       base symmetric;
+       base encryption_mode;
+       description
+         "Counter mode.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and
+          ISO/IEC 10116. ALG_ID: 0x0040";
+     }
+
+     identity TPM_ALG_OFB {
+       base tpm20;
+       base symmetric;
+       base encryption_mode;
+       description
+         "Output Feedback mode.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and
+          ISO/IEC 10116. ALG_ID: 0x0041";
+     }
+
+     identity TPM_ALG_CBC {
+       if-feature "tpm20";
+       base tpm20;
+       base symmetric;
+       base encryption_mode;
+       description
+         "Cipher Block Chaining mode.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and
+          ISO/IEC 10116. ALG_ID: 0x0042";
+     }
+
+     identity TPM_ALG_CFB {
+       if-feature "tpm20";
+       base tpm20;
+       base symmetric;
+       base encryption_mode;
+       description
+         "Cipher Feedback mode.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and
+          ISO/IEC 10116. ALG_ID: 0x0043";
+     }
+
+     identity TPM_ALG_ECB {
+       if-feature "tpm20";
+       base tpm20;
+       base symmetric;
+       base encryption_mode;
+       description
+         "Electronic Codebook mode.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and
+          ISO/IEC 10116. ALG_ID: 0x0044";
+     }
+
+     identity TPM_ALG_CCM {
+       if-feature "tpm20";
+       base tpm20;
+       base symmetric;
+       base signing;
+       base encryption_mode;
+       description
+         "Counter with Cipher Block Chaining--Message Authentication
+          Code (CCM).";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and
+          NIST SP800-38C. ALG_ID: 0x0050";
+     }
+
+     identity TPM_ALG_GCM {
+       if-feature "tpm20";
+       base tpm20;
+       base symmetric;
+       base signing;
+       base encryption_mode;
+       description
+         "Galois/Counter Mode (GCM).";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and
+          NIST SP800-38D. ALG_ID: 0x0051";
+     }
+
+     identity TPM_ALG_KW {
+       if-feature "tpm20";
+       base tpm20;
+       base symmetric;
+       base signing;
+       base encryption_mode;
+       description
+         "AES Key Wrap (KW).";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and
+          NIST SP800-38F. ALG_ID: 0x0052";
+     }
+
+     identity TPM_ALG_KWP {
+       if-feature "tpm20";
+       base tpm20;
+       base symmetric;
+       base signing;
+       base encryption_mode;
+       description
+         "AES Key Wrap with Padding (KWP).";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and
+          NIST SP800-38F. ALG_ID: 0x0053";
+     }
+
+     identity TPM_ALG_EAX {
+       if-feature "tpm20";
+       base tpm20;
+       base symmetric;
+       base signing;
+       base encryption_mode;
+       description
+         "Authenticated-Encryption Mode.";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and
+          NIST SP800-38F. ALG_ID: 0x0054";
+     }
+
+     identity TPM_ALG_EDDSA {
+       if-feature "tpm20";
+       base tpm20;
+       base asymmetric;
+       base signing;
+       description
+         "Edwards-curve Digital Signature Algorithm (PureEdDSA).";
+       reference
+         "TCG-Algos: TCG Algorithm Registry, Rev1.34, Table 3, and
+          RFC 8032. ALG_ID: 0x0060";
+     }
+   }
+
+
+
+
+
+

+Note that not all cryptographic functions are required for use by ietf-tpm-remote-attestation.yang. However, the full definition of Table 3 of [TCG-Algos] will allow use by additional YANG specifications. +

+
+
+

+IETF-TPM-Remote-Attestation.yangで使用するためにすべての暗号化関数が必要なわけではないことに注意してください。ただし、[TCG-Algos]の表3の完全な定義により、追加のYang仕様による使用が可能になります。 +

+
+
+
+
+
+3. IANA Considerations +
+
+
+
+3. IANAの考慮事項 +
+
+
+
+
+

+This document registers the following namespace URIs in the [XML-Registry] per [RFC3688]: +

+
+
+

+このドキュメントは、[rfc3688]ごとに[xml-registry]の次の名前空間URIを登録します。 +

+
+
+
+
+

+URI: +

+
+
+

+URI: +

+
+
+
+
+

+urn:ietf:params:xml:ns:yang:ietf-tpm-remote-attestation +

+
+
+

+urn：ietf：params：xml：ns：yang：ietf-tpm-remote-attestation +

+
+
+
+
+

+Registrant Contact: +

+
+
+

+登録者の連絡先： +

+
+
+
+
+

+The IESG. +

+
+
+

+IESG。 +

+
+
+
+
+

+XML: +

+
+
+

+XML: +

+
+
+
+
+

+N/A; the requested URI is an XML namespace. +

+
+
+

+n/a;要求されたURIはXMLネームスペースです。 +

+
+
+
+
+

+URI: +

+
+
+

+URI: +

+
+
+
+
+

+urn:ietf:params:xml:ns:yang:ietf-tcg-algs +

+
+
+

+urn：ietf：params：xml：ns：yang：ietf-tcg-algs +

+
+
+
+
+

+Registrant Contact: +

+
+
+

+登録者の連絡先： +

+
+
+
+
+

+The IESG. +

+
+
+

+IESG。 +

+
+
+
+
+

+XML: +

+
+
+

+XML: +

+
+
+
+
+

+N/A; the requested URI is an XML namespace. +

+
+
+

+n/a;要求されたURIはXMLネームスペースです。 +

+
+
+
+
+

+This document registers the following YANG modules in the registry [YANG-Parameters] per Section 14 of [RFC6020]: +

+
+
+

+このドキュメントでは、[RFC6020]のセクション14ごとにレジストリ[Yang-Parameters]の次のYangモジュールを登録します。 +

+
+
+
+
+

+Name: +

+
+
+

+名前： +

+
+
+
+
+

+ietf-tpm-remote-attestation +

+
+
+

+IETF-TPM-Remote-Attestation +

+
+
+
+
+

+Namespace: +

+
+
+

+名前空間： +

+
+
+
+
+

+urn:ietf:params:xml:ns:yang:ietf-tpm-remote-attestation +

+
+
+

+urn：ietf：params：xml：ns：yang：ietf-tpm-remote-attestation +

+
+
+
+
+

+Prefix: +

+
+
+

+プレフィックス： +

+
+
+
+
+

+tpm +

+
+
+

+TPM +

+
+
+
+
+

+Reference: +

+
+
+

+参照： +

+
+
+
+
+

+draft-ietf-rats-yang-tpm-charra (RFC form) +

+
+
+

+ドラフト-ITETF-RATS-YANG-TPM-CHARRA（RFCフォーム） +

+
+
+
+
+

+Name: +

+
+
+

+名前： +

+
+
+
+
+

+ietf-tcg-algs +

+
+
+

+IETF-TCG-ALGS +

+
+
+
+
+

+Namespace: +

+
+
+

+名前空間： +

+
+
+
+
+

+urn:ietf:params:xml:ns:yang:ietf-tcg-algs +

+
+
+

+urn：ietf：params：xml：ns：yang：ietf-tcg-algs +

+
+
+
+
+

+Prefix: +

+
+
+

+プレフィックス： +

+
+
+
+
+

+taa +

+
+
+

+タア +

+
+
+
+
+

+Reference: +

+
+
+

+参照： +

+
+
+
+
+

+draft-ietf-rats-yang-tpm-charra (RFC form) +

+
+
+

+ドラフト-ITETF-RATS-YANG-TPM-CHARRA（RFCフォーム） +

+
+
+
+
+
+4. Security Considerations +
+
+
+
+4. セキュリティに関する考慮事項 +
+
+
+
+
+

+The YANG module ietf-tpm-remote-attestation.yang specified in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446]. +

+
+
+

+このドキュメントで指定されたYangモジュールIETF-TPM-Remote-Attestation.Yangは、NetConf [RFC6241]やRestConf [RFC8040]などのネットワーク管理プロトコルを介してアクセスするように設計されたデータのスキーマを定義しています。最低のネットコン層は安全な輸送層であり、実装から実装の安全な輸送は安全なシェル（SSH）[RFC6242]です。最も低いRESTCONF層はHTTPSであり、実装対象の安全な輸送はTLS [RFC8446]です。 +

+
+
+
+
+

+The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. +

+
+
+

+ネットワーク構成アクセス制御モデル（NACM）[RFC8341]は、利用可能なすべてのNetConfまたはRestConfプロトコル操作とコンテンツの事前に構成されたサブセットに特定のNetConfまたはRestConfユーザーのアクセスを制限する手段を提供します。 +

+
+
+
+
+

+Of special consideration are the following nodes: +

+
+
+

+特別な考慮事項は次のノードです。 +

+
+
+
+
+

+* In the 'tpms' container, the 'certificates' will expose certificates used for attestation, potentially allowing selection of a certificate that might be compromised. The 'type' could also be misconfigured to represent a different type of key, which might alter how a Verifier might evaluate the results. +

+
+
+

+* 「TPMS」コンテナでは、「証明書」は証明に使用される証明書を公開し、侵害される可能性のある証明書の選択を可能にする可能性があります。「タイプ」は、異なるタイプのキーを表すために誤解される可能性があり、検証者が結果を評価する方法を変える可能性があります。 +

+
+
+
+
+

+* Within the 'attester-supported-algos' container, each leaf-list will expose and potentially allow changing of the encryption algorithms supported by a device. +

+
+
+

+* 「Astester-Supported-Algos」コンテナ内では、各リーフリストが露出し、デバイスでサポートされている暗号化アルゴリズムの変更を可能にします。 +

+
+
+
+
+

+There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., _config true_, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., _edit-config_) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes as well as their sensitivity/vulnerability: +

+
+
+

+このYangモジュールには、作成可能/クリエーション/削除可能な（つまり、デフォルトである_config true_）と定義されている多くのデータノードがあります。これらのデータノードは、一部のネットワーク環境で敏感または脆弱と見なされる場合があります。適切な保護なしにこれらのデータノードに操作を書き込む（_edit-config_）は、ネットワーク操作に悪影響を与える可能性があります。これらは、サブツリーとデータノード、および感度/脆弱性です。 +

+
+
+
+
+

+Container '/rats-support-structures/attester-supported-algos': +

+
+
+

+Container '/rats-support-structures/Attester-supported-algos'： +

+
+
+
+
+

+'tpm1 2-asymmetric-signing', 'tpm12-hash', 'tpm20-asymmetric-signing', and 'tpm20-hash'. All could be populated with algorithms that are not supported by the underlying physical TPM installed by the equipment vendor. A vendor should restrict the ability to configure unsupported algorithms. +

+
+
+

+'TPM1 2-ASYMMETRIC-SIGNING'、「TPM12-HASH」、「TPM20-ASYMMETRIC-SIGINA」、および「TPM20-HASH」。すべては、機器ベンダーによってインストールされている基礎となる物理TPMによってサポートされていないアルゴリズムを入力できます。ベンダーは、サポートされていないアルゴリズムを構成する機能を制限する必要があります。 +

+
+
+
+
+

+Container: '/rats-support-structures/tpms': +

+
+
+

+コンテナ： '/rats-support-structures/tpms'： +

+
+
+
+
+

+'name': Although shown as 'rw', it is system generated. Therefore, it should not be possible for an operator to add or remove a TPM from the configuration. +

+
+
+

+「名前」：「RW」として表示されていますが、システムが生成します。したがって、オペレーターが構成からTPMを追加または削除することはできないはずです。 +

+
+
+
+
+

+'tpm20-pcr-bank': It is possible to configure PCRs that are not being extended by system software for extraction. This could unnecessarily use TPM resources. +

+
+
+

+「TPM20-PCR-BANK」：抽出用のシステムソフトウェアによって拡張されていないPCRを構成することができます。これにより、TPMリソースを不必要に使用できます。 +

+
+
+
+
+

+'certificates': It is possible to provision a certificate that does not correspond to an AIK within the TPM 1.2, or to an Attestation Key (AK) within the TPM 2.0, respectively. In such a case, calls to an RPC requesting this specific certificate could result in either no response or a response from an unexpected TPM. +

+
+
+

+「証明書」：TPM 1.2内のAIKに対応しない証明書を、それぞれTPM 2.0内の証明キー（AK）に提供することができます。そのような場合、この特定の証明書を要求するRPCへの呼び出しは、予期しないTPMからの応答や応答のいずれかをもたらす可能性があります。 +

+
+
+
+
+

+RPC 'tpm12-challenge-response-attestation': +

+
+
+

+RPC 'TPM12-Challenge-Response-Attestation'： +

+
+
+
+
+

+The receiver of the RPC response must verify that the certificate is for an active AIK, i.e., the certificate has been confirmed by a third party as being able to support Attestation on the targeted TPM 1.2. +

+
+
+

+RPC応答の受信者は、証明書がアクティブなAIK用であることを確認する必要があります。つまり、証明書は、ターゲットを絞ったTPM 1.2の証明をサポートできるとサードパーティによって確認されています。 +

+
+
+
+
+

+RPC 'tpm20-challenge-response-attestation': +

+
+
+

+RPC 'TPM20-Challenge-Response-Attestation'： +

+
+
+
+
+

+The receiver of the RPC response must verify that the certificate is for an active AK, i.e., the private key confirmation of the quote signature within the RPC response has been confirmed by a third party to belong to an entity legitimately able to perform Attestation on the targeted TPM 2.0. +

+
+
+

+RPC応答の受信者は、証明書がアクティブなAK用であることを確認する必要があります。つまり、RPC応答内の引用署名の秘密の確認は、第三者によって、正当な証明を実行できるエンティティに属することが確認されています。ターゲットTPM 2.0。 +

+
+
+
+
+

+RPC 'log-retrieval': +

+
+
+

+rpc 'log-retrieval'： +

+
+
+
+
+

+Requesting a large volume of logs from the Attester could require significant system resources and create a denial of service. +

+
+
+

+Attesterから大量のログを要求すると、重要なシステムリソースが必要になり、サービスの拒否が必要になる場合があります。 +

+
+
+
+
+

+Information collected through the RPCs above could reveal specific versions of software and configurations of endpoints that could identify vulnerabilities on those systems. Therefore, RPCs should be protected by NACM [RFC8341] with a default setting of deny-all to limit the extraction of attestation data by only authorized Verifiers. +

+
+
+

+上記のRPCを介して収集された情報は、これらのシステムの脆弱性を特定できるエンドポイントのソフトウェアと構成の特定のバージョンを明らかにする可能性があります。したがって、RPCは、deny-allのデフォルト設定でNACM [RFC8341]によって保護され、認証された検証剤のみによって証明データの抽出を制限する必要があります。 +

+
+
+
+
+

+For the YANG module ietf-tcg-algs.yang, please use care when selecting specific algorithms. The introductory section of [TCG-Algos] highlights that some algorithms should be considered legacy, and recommends implementers and adopters diligently evaluate available information such as governmental, industrial, and academic research before selecting an algorithm for use. +

+
+
+

+YangモジュールIETF-TCG-ALGS.YANGについては、特定のアルゴリズムを選択する際には注意してください。[TCG-Algos]の紹介セクションは、いくつかのアルゴリズムをレガシーと見なすべきであることを強調し、使用するアルゴリズムを選択する前に、政府、産業、学術研究などの利用可能な情報を実装者と採用者に熱心に評価することを推奨しています。 +

+
+
+
+
+

+Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability: +

+
+
+

+このYangモジュールの読み取り可能なデータノードの一部は、一部のネットワーク環境で敏感または脆弱と見なされる場合があります。したがって、これらのデータノードへの読み取りアクセス（GET、GetConfig、または通知を介して）を制御することが重要です。これらは、サブツリーとデータノードとその感度/脆弱性です。 +

+
+
+
+
+

+Event logs (bios-log, ima-log, netequip-boot-log) typically contain hash values (digests) of running boot and OS software. Passive attackers can use these hash values to identify software versions and thus launch targeted attacks on known vulnerabilities. Hence, bios-log, ima-log, and netequip-boot-log are considered sensitive. +

+
+
+

+イベントログ（BIOS-LOG、IMA-LOG、NetEquip-Boot-Log）には、通常、実行中のブートソフトウェアのハッシュ値（ダイジェスト）が含まれています。受動的な攻撃者は、これらのハッシュ値を使用してソフトウェアバージョンを識別し、既知の脆弱性に対する標的攻撃を開始できます。したがって、BIOS-LOG、IMA-LOG、およびNet Equip-Boot-Logは敏感であると見なされます。 +

+
+
+
+
+

+Some of the RPC operations in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control access to these operations. These are the operations and their sensitivity/vulnerability: +

+
+
+

+このヤンモジュールのRPC操作の一部は、一部のネットワーク環境で敏感または脆弱と見なされる場合があります。したがって、これらの操作へのアクセスを制御することが重要です。これらは、操作とその感度/脆弱性です。 +

+
+
+
+
+

+The 'log-retrieval' RPC operation is considered sensitive since it enables retrieval of logs (bios-log, ima-log, netequip-boot-log) that typically contain hash values (digests) of running boot and OS software. This allows specifics of loaded software including BIOS and operating system software to be understood externally. +

+
+
+

+「log-retrieval」RPC操作は、通常、ランニングブートおよびOSソフトウェアのハッシュ値（ダイジェスト）を含むログ（BIOS-LOG、IMA-LOG、NET-Equip-Boot-Log）の取得を可能にするため、感度が高いと見なされます。これにより、BIOSやオペレーティングシステムソフトウェアを含むロードされたソフトウェアの詳細を外部で理解できます。 +

+
+
+
+
+

+The other two RPC operations, 'tpm20-challenge-response-attestation' and 'tpm12-challenge-response-attestation', will expose values indicating the internal operational state of the device. These values could also be correlated to specifics of running software as well. +

+
+
+

+他の2つのRPC操作「TPM20-Challenge-Response-Attestation」と「TPM12-Challenge-Response-Attestation」は、デバイスの内部動作状態を示す値を公開します。これらの値は、ランニングソフトウェアの詳細とも相関する可能性があります。 +

+
+
+
+
+
+5. References +
+
+
+
+5. 参考文献 +
+
+
+
+
+
+5.1. Normative References +
+
+
+
+5.1. 引用文献 +
+
+
+
+
+ 
+   [BIOS-Log] Trusted Computing Group, "TCG PC Client Platform Firmware
+              Profile Specification", Family "2.0" Level 00 Revision
+              1.03 Version 51, 1 May 2017,
+              <https://trustedcomputinggroup.org/wp-content/uploads/PC-C
+              lientSpecific_Platform_Profile_for_TPM_2p0_Systems_v51.pdf
+              >.
+
+
+
+
+
+ 
+   [CEL]      Trusted Computing Group, "Canonical Event Log Format",
+              Version 1.0 Revision 0.41, 25 February 2022,
+              <https://trustedcomputinggroup.org/wp-content/uploads/
+              TCG_IWG_CEL_v1_r0p41_pub.pdf>.
+
+
+
+
+
+ 
+   [IEEE-Std-1363-2000]
+              IEEE, "IEEE Standard Specifications for Public-Key
+              Cryptography", IEEE Std 1363-2000,
+              DOI 10.1109/IEEESTD.2000.92292, August 2000,
+              <https://ieeexplore.ieee.org/document/891000>.
+
+
+
+
+
+ 
+   [IEEE-Std-1363a-2004]
+              IEEE, "IEEE Standard Specifications for Public-Key
+              Cryptography - Amendment 1: Additional Techniques", IEEE
+              Std 1363a-2004, DOI 10.1109/IEEESTD.2004.94612, September
+              2004, <https://ieeexplore.ieee.org/document/1335427>.
+
+
+
+
+
+ 
+   [ISO-IEC-10116]
+              ISO/IEC, "Information technology - Security techniques -
+              Modes of operation for an n-bit block cipher", Edition 4,
+              ISO/IEC 10116:2017, July 2017,
+              <https://www.iso.org/standard/64575.html>.
+
+
+
+
+
+ 
+   [ISO-IEC-10118-3]
+              ISO/IEC, "IT Security techniques - Hash-functions - Part
+              3: Dedicated hash-functions", Edition 4, ISO/
+              IEC 10118-3:2018, October 2018,
+              <https://www.iso.org/standard/67116.html>.
+
+
+
+
+
+ 
+   [ISO-IEC-14888-3]
+              ISO/IEC, "Security techniques - Digital signatures with
+              appendix - Part 3: Discrete logarithm based mechanisms",
+              Edition 4, ISO/IEC 14888-3:2018, November 2018,
+              <https://www.iso.org/standard/76382.html>.
+
+
+
+
+
+ 
+   [ISO-IEC-15946-1]
+              ISO/IEC, "Information technology - Security techniques -
+              Cryptographic techniques based on elliptic curves - Part
+              1: General", Edition 3, ISO/IEC 15946-1:2016, July 2016,
+              <https://www.iso.org/standard/65480.html>.
+
+
+
+
+
+ 
+   [ISO-IEC-18033-3]
+              ISO/IEC, "Information technology - Security techniques -
+              Encryption algorithms - Part 3: Block ciphers", Edition 2,
+              ISO/IEC 18033-3:2010, December 2010,
+              <https://www.iso.org/standard/54531.html>.
+
+
+
+
+
+ 
+   [ISO-IEC-9797-1]
+              ISO/IEC, "Information technology - Security techniques -
+              Message Authentication Codes (MACs) - Part 1: Mechanisms
+              using a block cipher", Edition 2, ISO/IEC 9797-1:2011,
+              November 2011, <https://www.iso.org/standard/50375.html>.
+
+
+
+
+
+ 
+   [ISO-IEC-9797-2]
+              ISO/IEC, "Information security - Message authentication
+              codes (MACs) - Part 2: Mechanisms using a dedicated hash-
+              function", Edition 3, ISO/IEC 9797-2:2021, June 2021,
+              <https://www.iso.org/standard/75296.html>.
+
+
+
+
+
+ 
+   [NIST-FIPS-202]
+              NIST, "SHA-3 Standard: Permutation-Based Hash and
+              Extendable-Output Functions", NIST FIPS 202,
+              DOI 10.6028/NIST.FIPS.202, August 2015,
+              <https://csrc.nist.gov/publications/detail/fips/202/
+              final>.
+
+
+
+
+
+ 
+   [NIST-SP800-108]
+              Chen, L., "Recommendation for Key Derivation Using
+              Pseudorandom Functions",
+              DOI 10.6028/NIST.SP.800-108r1-upd1, NIST
+              SP 800-108r1-upd1, February 2024,
+              <https://csrc.nist.gov/pubs/sp/800/108/r1/upd1/final>.
+
+
+
+
+
+ 
+   [NIST-SP800-38C]
+              Dworkin, M., "Recommendation for Block Cipher Modes of
+              Operation: the CCM Mode for Authentication and
+              Confidentiality", NIST SP 800-38C,
+              DOI 10.6028/NIST.SP.800-38C, July 2007,
+              <https://csrc.nist.gov/publications/detail/sp/800-38c/
+              final>.
+
+
+
+
+
+ 
+   [NIST-SP800-38D]
+              Dworkin, M., "Recommendation for Block Cipher Modes of
+              Operation: Galois/Counter Mode (GCM) and GMAC", NIST
+              SP 800-38D, DOI 10.6028/NIST.SP.800-38D, November 2007,
+              <https://csrc.nist.gov/publications/detail/sp/800-38d/
+              final>.
+
+
+
+
+
+ 
+   [NIST-SP800-38F]
+              Dworkin, M., "Recommendation for Block Cipher Modes of
+              Operation: Methods for Key Wrapping", NIST SP 800-38F,
+              DOI 10.6028/NIST.SP.800-38F, December 2012,
+              <https://csrc.nist.gov/publications/detail/sp/800-38f/
+              final>.
+
+
+
+
+
+ 
+   [NIST-SP800-56A]
+              Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R.
+              Davis, "Recommendation for Pair-Wise Key-Establishment
+              Schemes Using Discrete Logarithm Cryptography", NIST
+              SP 800-56A Rev. 3, DOI 10.6028/NIST.SP.800-56Ar3, April
+              2018, <https://csrc.nist.gov/publications/detail/sp/800-
+              56a/rev-3/final>.
+
+
+
+
+
+ 
+   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
+              Hashing for Message Authentication", RFC 2104,
+              DOI 10.17487/RFC2104, February 1997,
+              <https://www.rfc-editor.org/info/rfc2104>.
+
+
+
+
+
+ 
+   [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>.
+
+
+
+
+
+ 
+   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
+              DOI 10.17487/RFC3688, January 2004,
+              <https://www.rfc-editor.org/info/rfc3688>.
+
+
+
+
+
+ 
+   [RFC6020]  Bjorklund, M., Ed., "YANG - A Data Modeling Language for
+              the Network Configuration Protocol (NETCONF)", RFC 6020,
+              DOI 10.17487/RFC6020, October 2010,
+              <https://www.rfc-editor.org/info/rfc6020>.
+
+
+
+
+
+ 
+   [RFC6241]  Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
+              and A. Bierman, Ed., "Network Configuration Protocol
+              (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
+              <https://www.rfc-editor.org/info/rfc6241>.
+
+
+
+
+
+ 
+   [RFC6242]  Wasserman, M., "Using the NETCONF Protocol over Secure
+              Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
+              <https://www.rfc-editor.org/info/rfc6242>.
+
+
+
+
+
+ 
+   [RFC6933]  Bierman, A., Romascanu, D., Quittek, J., and M.
+              Chandramouli, "Entity MIB (Version 4)", RFC 6933,
+              DOI 10.17487/RFC6933, May 2013,
+              <https://www.rfc-editor.org/info/rfc6933>.
+
+
+
+
+
+ 
+   [RFC6991]  Schoenwaelder, J., Ed., "Common YANG Data Types",
+              RFC 6991, DOI 10.17487/RFC6991, July 2013,
+              <https://www.rfc-editor.org/info/rfc6991>.
+
+
+
+
+
+ 
+   [RFC8017]  Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
+              "PKCS #1: RSA Cryptography Specifications Version 2.2",
+              RFC 8017, DOI 10.17487/RFC8017, November 2016,
+              <https://www.rfc-editor.org/info/rfc8017>.
+
+
+
+
+
+ 
+   [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
+              Signature Algorithm (EdDSA)", RFC 8032,
+              DOI 10.17487/RFC8032, January 2017,
+              <https://www.rfc-editor.org/info/rfc8032>.
+
+
+
+
+
+ 
+   [RFC8040]  Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
+              Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
+              <https://www.rfc-editor.org/info/rfc8040>.
+
+
+
+
+
+ 
+   [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>.
+
+
+
+
+
+ 
+   [RFC8341]  Bierman, A. and M. Bjorklund, "Network Configuration
+              Access Control Model", STD 91, RFC 8341,
+              DOI 10.17487/RFC8341, March 2018,
+              <https://www.rfc-editor.org/info/rfc8341>.
+
+
+
+
+
+ 
+   [RFC8348]  Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, "A
+              YANG Data Model for Hardware Management", RFC 8348,
+              DOI 10.17487/RFC8348, March 2018,
+              <https://www.rfc-editor.org/info/rfc8348>.
+
+
+
+
+
+ 
+   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
+              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
+              <https://www.rfc-editor.org/info/rfc8446>.
+
+
+
+
+
+ 
+   [RFC9334]  Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
+              W. Pan, "Remote ATtestation procedureS (RATS)
+              Architecture", RFC 9334, DOI 10.17487/RFC9334, January
+              2023, <https://www.rfc-editor.org/info/rfc9334>.
+
+
+
+
+
+ 
+   [RFC9642]  Watsen, K., "A YANG Data Model for a Keystore", RFC 9642,
+              DOI 10.17487/RFC9642, October 2024,
+              <https://www.rfc-editor.org/info/rfc9642>.
+
+
+
+
+
+ 
+   [RFC9683]  Fedorkow, G. C., Ed., Voit, E., and J. Fitzgerald-McKay,
+              "Remote Integrity Verification of Network Devices
+              Containing Trusted Platform Modules", RFC 9683,
+              DOI 10.17487/RFC9683, December 2024,
+              <https://www.rfc-editor.org/info/rfc9683>.
+
+
+
+
+
+ 
+   [TCG-Algos]
+              Trusted Computing Group, "TCG Algorithm Registry", Family
+              "2.0" Level 00 Revision 01.34, 24 August 2023,
+              <https://trustedcomputinggroup.org/wp-content/uploads/TCG-
+              Algorithm-Registry-Revision-1.34_pub-1.pdf>.
+
+
+
+
+
+ 
+   [TPM1.2]   Trusted Computing Group, "TPM 1.2 Main Specification", TPM
+              Main Specification Level 2 Version 1.2, Revision 116, 1
+              March 2011, <https://trustedcomputinggroup.org/resource/
+              tpm-main-specification/>.
+
+
+
+
+
+ 
+   [TPM1.2-Commands]
+              Trusted Computing Group, "TPM Main Part 3 Commands", TPM
+              Main Specification Level 2 Version 1.2, Revision 116, 1
+              March 2011, <https://trustedcomputinggroup.org/wp-
+              content/uploads/TPM-Main-Part-
+              3-Commands_v1.2_rev116_01032011.pdf>.
+
+
+
+
+
+ 
+   [TPM1.2-Structures]
+              Trusted Computing Group, "TPM Main Part 2 TPM Structures",
+              TPM Main Specification Level 2 Version 1.2, Revision 116,
+              1 March 2011, <https://trustedcomputinggroup.org/wp-
+              content/uploads/TPM-Main-Part-2-TPM-
+              Structures_v1.2_rev116_01032011.pdf>.
+
+
+
+
+
+ 
+   [TPM2.0]   Trusted Computing Group, "TPM 2.0 Library", Trusted
+              Platform Module Library Specification, Family "2.0", Level
+              00, Revision 01.83, March 2024,
+              <https://trustedcomputinggroup.org/resource/tpm-library-
+              specification/>.
+
+
+
+
+
+ 
+   [TPM2.0-Arch]
+              Trusted Computing Group, "Trusted Platform Module Library
+              Part 1: Architecture", Family "2.0", Level 00, Revision
+              01.83, 25 January 2024,
+              <https://trustedcomputinggroup.org/wp-content/uploads/TPM-
+              2.0-1.83-Part-1-Architecture.pdf>.
+
+
+
+
+
+ 
+   [TPM2.0-Key]
+              Trusted Computing Group, "TPM 2.0 Keys for Device Identity
+              and Attestation", Version 1.00, Revision 12, 8 October
+              2021, <https://trustedcomputinggroup.org/wp-
+              content/uploads/TPM-2p0-Keys-for-Device-Identity-and-
+              Attestation_v1_r12_pub10082021.pdf>.
+
+
+
+
+
+ 
+   [TPM2.0-Structures]
+              Trusted Computing Group, "Trusted Platform Module Library
+              Part 2: Structures", Family "2.0", Level 00, Revision
+              01.83, 25 January 2024,
+              <https://trustedcomputinggroup.org/wp-content/uploads/TPM-
+              2.0-1.83-Part-2-Structures.pdf>.
+
+
+
+
+
+ 
+   [UEFI-Secure-Boot]
+              Unified Extensible Firmware Interface (UEFI) Forum, Inc.,
+              "Unified Extensible Firmware Interface (UEFI)
+              Specification", Section 32.1: Secure Boot, Version 2.10,
+              29 August 2022,
+              <https://uefi.org/sites/default/files/resources/
+              UEFI_Spec_2_10_Aug29.pdf>.
+
+
+
+
+
+
+5.2. Informative References +
+
+
+
+5.2. 参考引用 +
+
+
+
+
+ 
+   [IMA-Template-Management]
+              The kernel development community, "IMA Template Management
+              Mechanism", Linux Kernel 6.11, 15 September 2024,
+              <https://www.kernel.org/doc/html/v6.11/security/IMA-
+              templates.html>.
+
+
+
+
+
+ 
+   [NIST-915121]
+              NIST, "True Randomness Can't be Left to Chance: Why
+              entropy is important for information security",
+              <https://tsapps.nist.gov/publication/
+              get_pdf.cfm?pub_id=915121>.
+
+
+
+
+
+ 
+   [RATS-Interaction-Models]
+              Birkholz, H., Eckel, M., Pan, W., and E. Voit, "Reference
+              Interaction Models for Remote Attestation Procedures",
+              Work in Progress, Internet-Draft, draft-ietf-rats-
+              reference-interaction-models-11, 22 July 2024,
+              <https://datatracker.ietf.org/doc/html/draft-ietf-rats-
+              reference-interaction-models-11>.
+
+
+
+
+
+ 
+   [XML-Registry]
+              IANA, "IETF XML Registry",
+              <https://www.iana.org/assignments/xml-registry/>.
+
+
+
+
+
+ 
+   [YANG-Parameters]
+              IANA, "YANG Parameters",
+              <https://www.iana.org/assignments/yang-parameters/>.
+
+
+
+
+
+
+Appendix A. Integrity Measurement Architecture (IMA) +
+
+
+
+付録A. 整合性測定アーキテクチャ（IMA） +
+
+
+
+
+

+IMA extends the principles of Measured Boot [TPM2.0-Arch] and Secure Boot [UEFI-Secure-Boot] to the Linux operating system, applying it to operating system applications and files. IMA has been part of the Linux integrity subsystem of the Linux kernel since 2009 (kernel version 2.6.30). The IMA mechanism represented by the YANG module in this specification is rooted in the kernel version 5.16 [IMA-Template-Management]. IMA enables the protection of system integrity by collecting (commonly referred to as measuring) and storing measurements (called Claims in the context of IETF RATS) of files before execution so that these measurements can be used later, at system runtime, in remote attestation procedures. IMA acts in support of the Appraisal of Evidence (which includes measurement Claims) by leveraging Reference Values stored in extended file attributes. +

+
+
+

+IMAは、測定されたブート[TPM2.0-ARCH]およびセキュアブート[UEFI-Secure-Boot]の原理をLinuxオペレーティングシステムに拡張し、オペレーティングシステムのアプリケーションとファイルに適用します。IMAは、2009年以来、LinuxカーネルのLinux Integrityサブシステムの一部です（Kernelバージョン2.6.30）。この仕様でYangモジュールで表されるIMAメカニズムは、カーネルバージョン5.16 [IMA-Template-Management]に根ざしています。IMAは、実行前にファイルのファイルの測定値（IETFラットのコンテキストでクレーム）を収集し（一般に測定と呼ばれる）、保存することにより、システムの整合性の保護を可能にします。。IMAは、拡張ファイル属性に保存されている参照値を活用することにより、証拠の評価（測定クレームを含む）を支持して行動します。 +

+
+
+
+
+

+In support of the Appraisal of Evidence, IMA maintains an ordered list (with no duplicates) of measurements in kernel space, the Stored Measurement Log (SML), for all files that have been measured before execution since the operating system was started. Although IMA can be used without a TPM, it is typically used in conjunction with a TPM to anchor the integrity of the SML in a hardware-protected secure storage location, i.e., PCRs provided by TPMs. IMA provides the SML in both binary and ASCII representations in the Linux security file system _securityfs_ (/sys/kernel/security/ima/). +

+
+
+

+証拠の評価を支持して、IMAは、オペレーティングシステムが開始されてから実行前に測定されたすべてのファイルに対して、保存された測定ログ（SML）であるカーネル空間での測定値（重複なし）を維持しています。IMAはTPMなしで使用できますが、通常、TPMと組み合わせて使用され、ハードウェアで保護されたセキュアストレージの場所、つまりTPMによって提供されるPCRにSMLの整合性を固定します。IMAは、Linuxセキュリティファイルシステム_SecurityFS_（/sys/kernel/security/ima/）でバイナリ表現とASCII表現の両方でSMLを提供します。 +

+
+
+
+
+

+IMA templates define the format of the SML, i.e., which fields are included in a log record. Examples are file path, file hash, user ID, group ID, file signature, and extended file attributes. IMA comes with a set of predefined template formats and also allows a custom format, i.e., a format consisting of template fields supported by IMA. Template usage is typically determined by boot arguments passed to the kernel. Alternatively, the format can also be hard-coded into custom kernels. IMA templates and fields are extensible in the kernel source code. As a result, more template fields can be added in the future. +

+
+
+

+IMAテンプレートは、SMLの形式、つまりログレコードに含まれるフィールドを定義します。例は、ファイルパス、ファイルハッシュ、ユーザーID、グループID、ファイル署名、拡張ファイル属性です。IMAには、事前定義されたテンプレート形式のセットが付属しており、カスタム形式、つまりIMAがサポートするテンプレートフィールドで構成される形式も許可しています。テンプレートの使用は、通常、カーネルに渡されたブート引数によって決定されます。または、この形式をカスタムカーネルにハードコーディングすることもできます。IMAテンプレートとフィールドは、カーネルソースコードで拡張可能です。その結果、将来、より多くのテンプレートフィールドを追加できます。 +

+
+
+
+
+

+IMA policies define which files are measured using the IMA policy language. Built-in policies can be passed as boot arguments to the kernel. Custom IMA policies can be defined once during runtime or be hard-coded into a custom kernel. If no policy is defined, no measurements are taken and IMA is effectively disabled. +

+
+
+

+IMAポリシーは、IMAポリシー言語を使用して測定されるファイルを定義します。組み込みのポリシーは、カーネルのブート引数として渡すことができます。カスタムIMAポリシーは、ランタイム中に1回定義することも、カスタムカーネルにハードコーディングすることもできます。ポリシーが定義されていない場合、測定は行われず、IMAは効果的に無効になります。 +

+
+
+
+
+

+A comprehensive description of the content fields of the Linux IMA TLV format can be found in Table 16 of the Canonical Event Log (CEL) specification [CEL]. The CEL specification also illustrates the use of templates to enable extended or customized IMA TLV formats in Section 5.1.6. +

+
+
+

+Linux IMA TLV形式のコンテンツフィールドの包括的な説明は、標準イベントログ（CEL）の表16の表16にあります。CEL仕様は、セクション5.1.6で拡張またはカスタマイズされたIMA TLV形式を有効にするためのテンプレートの使用も示しています。 +

+
+
+
+
+
+Appendix B. IMA for Network Equipment Boot Logs +
+
+
+
+付録B. ネットワーク機器のブートログ用のIMA +
+
+
+
+
+

+Network equipment can generally implement similar IMA-protected functions to generate measurements (Claims) about the boot process of a device and enable corresponding remote attestation. Network Equipment Boot Logs combine the measurement and logging of boot components and operating system components (executables and files) into a single log file in a format identical to the IMA format. Note that the format used for logging measurement of boot components in this scheme differs from the boot logging strategy described elsewhere in this document. +

+
+
+

+ネットワーク機器は一般に、同様のIMA保護機能を実装して、デバイスのブートプロセスに関する測定（クレーム）を生成し、対応するリモートの証明を有効にすることができます。ネットワーク機器ブートログは、ブートコンポーネントとオペレーティングシステムコンポーネント（実行可能ファイルとファイル）の測定とロギングを、IMA形式と同一の形式で単一のログファイルに組み合わせます。このスキームのブートコンポーネントのロギング測定に使用される形式は、このドキュメントの他の場所で説明されているブートロギング戦略とは異なることに注意してください。 +

+
+
+
+
+

+During the boot process of the network device, i.e., from BIOS to the end of the operating system and user-space, all files executed can be measured and logged in the order of their execution. When the Verifier initiates a remote attestation process (e.g., challenge-response remote attestation as defined in this document), the network equipment takes on the role of an Attester and can convey to the Verifier Claims that comprise the measurement log as well as the corresponding PCR values (Evidence) of a TPM. +

+
+
+

+ネットワークデバイスのブートプロセス、つまり、BIOSからオペレーティングシステムとユーザースペースの終わりまで、実行されたすべてのファイルを測定して実行することができます。検証者がリモートの証明プロセス（このドキュメントで定義されているチャレンジ応答リモートの証明）を開始すると、ネットワーク機器はアテスターの役割を引き受け、対応する測定ログと測定ログを構成する検証者に伝えることができますTPMのPCR値（証拠）。 +

+
+
+
+
+

+The Verifier can appraise the integrity (compliance with the Reference Values) of each executed file by comparing its measured value with the Reference Value. Based on the execution order, the Verifier can compute a PCR Reference Value (by replaying the log) and compare it to the measurement log Claims obtained in conjunction with the PCR Evidence to assess their trustworthiness with respect to an intended operational state. +

+
+
+

+検証者は、測定値を参照値と比較することにより、実行された各ファイルの整合性（参照値のコンプライアンス）を評価できます。実行順序に基づいて、検証者は（ログを再生することにより）PCR参照値を計算し、PCRの証拠と併せて得られた測定ログクレームと比較して、意図した運用状態に関する信頼性を評価します。 +

+
+
+
+
+

+Network equipment usually executes multiple components in parallel. This holds not only during the operating system loading phase, but also even during the BIOS boot phase. With this measurement log mechanism, network equipment can assume the role of an Attester, proving to the Verifier the trustworthiness of its boot process. Using the measurement log, Verifiers can precisely identify mismatching log entries to infer potentially tampered components. +

+
+
+

+ネットワーク機器は通常、複数のコンポーネントを並行して実行します。これは、オペレーティングシステムの読み込み段階だけでなく、BIOSブートフェーズでも保持されます。この測定ログメカニズムにより、ネットワーク機器は、ブートプロセスの信頼性を検証剤に証明し、攻撃者の役割を引き受けることができます。測定ログを使用すると、検証剤はログエントリの不一致を正確に識別して、潜在的に改ざんされたコンポーネントを推測できます。 +

+
+
+
+
+

+This mechanism also supports scenarios that modify files on the Attester that are subsequently executed during the boot phase (e.g., updating/patching) by simply updating the appropriate Reference Values in Reference Integrity Manifests that inform Verifiers about how an Attester is composed. +

+
+
+

+このメカニズムは、アテスター上のファイルを変更するシナリオもサポートしています。これは、ブートフェーズ中に実行される（たとえば、更新/パッチング）、参照整合性の適切な参照値を更新するだけで、検証者に攻撃者がどのように構成されているかを確認するだけです。 +

+
+
+
+
+
+Authors' Addresses +
+
+
+
+著者のアドレス +
+
+
+
+
+ 
+   Henk Birkholz
+   Fraunhofer SIT | ATHENE Center
+   Rheinstrasse 75
+   64295 Darmstadt
+   Germany
+   Email: henk.birkholz@ietf.contact
+
+
+
+
+
+ 
+   Michael Eckel
+   Fraunhofer SIT | ATHENE Center
+   Rheinstrasse 75
+   64295 Darmstadt
+   Germany
+   Email: michael.eckel@sit.fraunhofer.de
+
+
+
+
+
+ 
+   Shwetha Bhandari
+   ThoughtSpot
+   Email: shwetha.bhandari@thoughtspot.com
+
+
+
+
+
+ 
+   Eric Voit
+   Cisco Systems
+   Email: evoit@cisco.com
+
+
+
+
+
+ 
+   Bill Sulzen
+   Cisco Systems
+   Email: bsulzen@cisco.com
+
+
+
+
+
+ 
+   Liang Xia (Frank)
+   Huawei Technologies
+   Yuhuatai District
+   101 Software Avenue
+   Nanjing
+   Jiangsu, 210012
+   China
+   Email: Frank.Xialiang@huawei.com
+
+
+
+
+
+ 
+   Tom Laffey
+   Hewlett Packard Enterprise
+   Email: tom.laffey@hpe.com
+
+
+
+
+
+ 
+   Guy C. Fedorkow
+   Juniper Networks
+   10 Technology Park Drive
+   Westford, Massachusetts 01886
+   United States of America
+   Email: gfedorkow@juniper.net
+
+
+
+
+ + + diff --git a/html/rfc9686.html b/html/rfc9686.html new file mode 100644 index 000000000..bb0bd386a --- /dev/null +++ b/html/rfc9686.html @@ -0,0 +1,2312 @@ + + + + + + RFC 9686 - Registering Self-Generated IPv6 Addresses Using DHCPv6 日本語訳 + + + + + + + + + + + + +
+
+ + + +
+
+
+ + +
+
+
+ 
+Internet Engineering Task Force (IETF)                         W. Kumari
+Request for Comments: 9686                                   Google, LLC
+Category: Standards Track                                    S. Krishnan
+ISSN: 2070-1721                                      Cisco Systems, Inc.
+                                                                R. Asati
+                                                             Independent
+                                                              L. Colitti
+                                                              J. Linkova
+                                                             Google, LLC
+                                                                S. Jiang
+                                                                    BUPT
+                                                           December 2024
+
+
+
+
+
+
+Registering Self-Generated IPv6 Addresses Using DHCPv6 +
+
+
+
+DHCPV6を使用して、自己生成IPv6アドレスを登録します +
+
+
+
+
+
+Abstract +
+
+
+
+概要 +
+
+
+
+
+

+This document defines a method to inform a DHCPv6 server that a device has one or more self-generated or statically configured addresses. +

+
+
+

+このドキュメントでは、DHCPV6サーバーに、デバイスに1つ以上の自己生成または静的に構成されたアドレスがあることを通知する方法を定義します。 +

+
+
+
+
+
+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/rfc9686. +

+
+
+

+このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9686で取得できます。 +

+
+
+
+
+
+Copyright Notice +
+
+
+
+著作権表示 +
+
+
+
+
+

+Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. +

+
+
+

+著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。 +

+
+
+
+
+

+This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. +

+
+
+

+このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。 +

+
+
+
+
+
+Table of Contents +
+
+
+
+目次 +
+
+
+
+
+ 
+   1.  Introduction
+   2.  Conventions and Definitions
+   3.  Registration Mechanism Overview
+   4.  DHCPv6 Address Registration Procedure
+     4.1.  DHCPv6 Address Registration Option
+     4.2.  DHCPv6 Address Registration Request Message
+       4.2.1.  Server Message Processing
+     4.3.  DHCPv6 Address Registration Acknowledgement
+     4.4.  Signaling Address Registration Support
+     4.5.  Retransmission
+     4.6.  Registration Expiry and Refresh
+       4.6.1.  SLAAC Addresses
+       4.6.2.  Statically Assigned Addresses
+       4.6.3.  Transmitting Refreshes
+   5.  Client Configuration
+   6.  Security Considerations
+   7.  Privacy Considerations
+   8.  IANA Considerations
+   9.  References
+     9.1.  Normative References
+     9.2.  Informative References
+   Acknowledgements
+   Contributors
+   Authors' Addresses
+
+
+
+
+
+
+1. Introduction +
+
+
+
+1. はじめに +
+
+
+
+
+

+It is very common operational practice, especially in enterprise networks, to use IPv4 DHCP logs for troubleshooting or forensics purposes. An example of this includes a help desk dealing with a ticket such as "The CEO's laptop cannot connect to the printer"; if the Media Access Control (MAC) address of the printer is known (for example, from an inventory system), the printer's IPv4 address can be retrieved from the DHCP log or lease table and the printer can be pinged to determine if it is reachable. Another common example is a security operations team discovering suspicious events in outbound firewall logs and then consulting DHCP logs to determine which employee's laptop had that IPv4 address at that time so that they can quarantine it and remove the malware. +

+
+
+

+トラブルシューティングまたはフォレンジックの目的でIPv4 DHCPログを使用することは、特にエンタープライズネットワークで非常に一般的な運用慣行です。この例には、「CEOのラップトップはプリンターに接続できない」などのチケットを扱うヘルプデスクが含まれます。プリンターのメディアアクセス制御（MAC）アドレスが既知である場合（たとえば、インベントリシステムから）、プリンターのIPv4アドレスをDHCPログまたはリーステーブルから取得でき、プリンターをPingで到達できるかどうかを判断できます。。もう1つの一般的な例は、アウトバウンドファイアウォールログで疑わしいイベントを発見し、DHCPログに相談して、その時点でどの従業員のラップトップがそのIPv4アドレスを持っていたかを判断して、それを検疫してマルウェアを削除できるようにするセキュリティオペレーションチームです。 +

+
+
+
+
+

+This operational practice relies on the DHCP server knowing the IP address assignments. This works quite well for IPv4 addresses, as most addresses are either assigned by DHCP [RFC2131] or statically configured by the network operator. For IPv6, however, this practice is much harder to implement, as devices often self-configure IPv6 addresses via Stateless Address Autoconfiguration (SLAAC) [RFC4862]. +

+
+
+

+この運用慣行は、IPアドレスの割り当てを知っているDHCPサーバーに依存しています。ほとんどのアドレスはDHCP [RFC2131]によって割り当てられているか、ネットワークオペレーターによって静的に構成されているため、これはIPv4アドレスで非常にうまく機能します。ただし、IPv6の場合、このプラクティスは実装するのがはるかに困難です。これは、DevicesがStateless Address Autoconfiguration（SLAAC）[RFC4862]を介して自己構成されることが多いため、実装がはるかに困難です。 +

+
+
+
+
+

+This document provides a mechanism for a device to inform the DHCPv6 server that the device has a self-configured IPv6 address (or has a statically configured address), and thus provides parity with IPv4 by making DHCPv6 infrastructure aware of self-assigned IPv6 addresses. +

+
+
+

+このドキュメントは、デバイスにDHCPV6サーバーに、デバイスに自己構成のIPv6アドレスがあること（または静的に構成されたアドレスがある）を通知するメカニズムを提供し、したがって、DHCPV6インフラストラクチャに自己割り当てされたIPv6アドレスを認識することによりIPv4のパリティを提供します。 +

+
+
+
+
+
+2. Conventions and Definitions +
+
+
+
+2. 慣習と定義 +
+
+
+
+
+

+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. +

+
+
+

+「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。 +

+
+
+
+
+
+3. Registration Mechanism Overview +
+
+
+
+3. 登録メカニズムの概要 +
+
+
+
+
+

+The DHCPv6 protocol is used as the address registration protocol and a DHCPv6 server performs the role of an address registration server. This document introduces a new Address Registration (OPTION_ADDR_REG_ENABLE) option, which indicates that the server supports the registration mechanism. Before registering any addresses, the client MUST determine whether the network supports address registration. It can do this by including the Address Registration option code in the Option Request option (see Section 21.7 of [RFC8415]) of the Information-Request, Solicit, Request, Renew, or Rebind messages it sends to the server as part of the regular stateless or stateful DHCPv6 configuration process. If the server supports address registration, it includes an Address Registration option in its Advertise or Reply messages. To avoid undesired multicast traffic, if the DHCPv6 infrastructure does not support (or is not willing to receive) any address registration information, the client MUST NOT register any addresses using the mechanism in this specification. Otherwise, the client registers addresses as described below. +

+
+
+

+DHCPV6プロトコルはアドレス登録プロトコルとして使用され、DHCPV6サーバーはアドレス登録サーバーの役割を実行します。このドキュメントでは、新しいアドレス登録（option_addr_reg_enable）オプションを紹介します。これは、サーバーが登録メカニズムをサポートしていることを示します。アドレスを登録する前に、クライアントはネットワークがアドレス登録をサポートするかどうかを判断する必要があります。これは、情報の要求、勧誘、要求、更新、または通常の一部としてサーバーに送信するメッセージの一部の登録オプションコード（[RFC8415]のセクション21.7を参照[RFC8415]を参照）を含めることで行うことができます。ステートレスまたはステートフルなDHCPV6構成プロセス。サーバーがアドレス登録をサポートしている場合、アドレス登録オプションが広告または返信メッセージに含まれています。望ましくないマルチキャストトラフィックを避けるために、DHCPV6インフラストラクチャがアドレス登録情報をサポートしていない（または受け取る意思がない）場合、クライアントはこの仕様のメカニズムを使用してアドレスを登録してはなりません。それ以外の場合、クライアントは以下に説明するようにアドレスを登録します。 +

+
+
+
+
+

+After successfully assigning a self-generated or statically configured valid IPv6 address [RFC4862] on one of its interfaces, a client implementing this specification multicasts an ADDR-REG-INFORM message (see Section 4.2) in order to inform the DHCPv6 server that this self-generated address is in use. Each ADDR-REG-INFORM message contains a DHCPv6 Identity Association (IA) Address option [RFC8415] to specify the address being registered. +

+
+
+

+自己生成または静的に構成された有効なIPv6アドレス[RFC4862]をそのインターフェイスの1つに割り当てた後、この仕様を実装するクライアントは、DHCPV6サーバーにこの自己を通知するために、AddR-Reg-Informメッセージ（セクション4.2を参照）を実装します（セクション4.2を参照）- 生成されたアドレスが使用されています。各addr-reg-informメッセージには、登録されているアドレスを指定するために、DHCPV6アイデンティティアソシエーション（IA）アドレスオプション[RFC8415]が含まれています。 +

+
+
+
+
+

+The address registration mechanism overview is shown in Figure 1. +

+
+
+

+アドレス登録メカニズムの概要を図1に示します。 +

+
+
+
+
+ 
+   +--------+        +------------------+       +---------------+
+   | CLIENT |        | FIRST-HOP ROUTER |       | DHCPv6 SERVER |
+   +--------+        +---------+--------+       +-------+-------+
+       |      SLAAC            |                        |
+       |<--------------------> |                        |
+       |                       |                        |
+       |                                                |
+       |  src: link-local address                       |
+       | -------------------------------------------->  |
+       |    INFORMATION-REQUEST or SOLICIT/...          |
+       |       - OPTION REQUEST OPTION                  |
+       |          -- OPTION_ADDR_REG_ENABLE             |
+       |                                                |
+       |    ...                                         |
+       |                                                |
+       |                                                |
+       |<---------------------------------------------  |
+       |     REPLY or ADVERTISE MESSAGE                 |
+       |       - OPTION_ADDR_REG_ENABLE                 |
+       |                                                |
+       |                                                |
+       |  src: address being registered                 |
+       | -------------------------------------------->  |
+       |    ADDR-REG-INFORM MESSAGE                     |Register/
+       |                                                |log addresses
+       |                                                |
+       |                                                |
+       | <--------------------------------------------  |
+       |        ADDR-REG-REPLY MESSAGE                  |
+       |                                                |
+
+
+
+
+
+

+Figure 1: Address Registration Procedure Overview +

+
+
+

+図1：アドレス登録手順の概要 +

+
+
+
+
+
+4. DHCPv6 Address Registration Procedure +
+
+
+
+4. DHCPV6アドレス登録手順 +
+
+
+
+
+
+4.1. DHCPv6 Address Registration Option +
+
+
+
+4.1. DHCPV6アドレス登録オプション +
+
+
+
+
+

+The Address Registration option (OPTION_ADDR_REG_ENABLE) indicates that the server supports the mechanism described in this document. The format of the Address Registration option is described as follows: +

+
+
+

+アドレス登録オプション（option_addr_reg_enable）は、サーバーがこのドキュメントで説明されているメカニズムをサポートしていることを示します。アドレス登録オプションの形式は次のように説明されています。 +

+
+
+
+
+ 
+     0                   1                   2                   3
+     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |          option-code          |           option-len          |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+

+Figure 2: DHCPv6 Address Registration Option +

+
+
+

+図2：DHCPV6アドレス登録オプション +

+
+
+
+
+

+option-code: +

+
+
+

+オプションコード： +

+
+
+
+
+

+OPTION_ADDR_REG_ENABLE (148) +

+
+
+

+option_addr_reg_enable（148） +

+
+
+
+
+

+option-len: +

+
+
+

+オプションレン： +

+
+
+
+
+

+0 +

+
+
+

+0 +

+
+
+
+
+

+If a client has the address registration mechanism enabled, it MUST include this option in all Option Request options that it sends. +

+
+
+

+クライアントがアドレス登録メカニズムを有効にしている場合、送信するすべてのオプション要求オプションにこのオプションを含める必要があります。 +

+
+
+
+
+

+A server that is configured to support the address registration mechanism MUST include this option in Advertise and Reply messages if the client message it is replying to contained this option in the Option Request option. +

+
+
+

+アドレス登録メカニズムをサポートするように構成されているサーバーは、このオプションをAdvertiseメッセージに含める必要があります。 +

+
+
+
+
+
+4.2. DHCPv6 Address Registration Request Message +
+
+
+
+4.2. DHCPV6アドレス登録リクエストメッセージ +
+
+
+
+
+

+The DHCPv6 client sends an ADDR-REG-INFORM message to inform that an IPv6 address is assigned to the client's interface. The format of the ADDR-REG-INFORM message is described as follows: +

+
+
+

+DHCPV6クライアントは、IPv6アドレスがクライアントのインターフェイスに割り当てられていることを通知するために、addr-reg-informメッセージを送信します。Addr-Reg-Informメッセージの形式は、次のように説明されています。 +

+
+
+
+
+ 
+     0                   1                   2                   3
+     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |    msg-type   |               transaction-id                  |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                                                               |
+    .                            options                            .
+    .                           (variable)                          .
+    |                                                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+

+Figure 3: DHCPv6 ADDR-REG-INFORM Message +

+
+
+

+図3：DHCPV6 Addr-Reg-Informメッセージ +

+
+
+
+
+

+msg-type: +

+
+
+

+MSGタイプ： +

+
+
+
+
+

+Identifies the DHCPv6 message type; set to ADDR-REG-INFORM (36). +

+
+
+

+DHCPV6メッセージタイプを識別します。Addr-Reg-Inform（36）に設定します。 +

+
+
+
+
+

+transaction-id: +

+
+
+

+Transaction-ID： +

+
+
+
+
+

+The transaction ID for this message exchange. +

+
+
+

+このメッセージ交換のトランザクションID。 +

+
+
+
+
+

+options: +

+
+
+

+オプション： +

+
+
+
+
+

+The options carried in this message. +

+
+
+

+このメッセージに掲載されたオプション。 +

+
+
+
+
+

+The client MUST generate a transaction ID as described in [RFC8415] and insert this value in the transaction-id field. +

+
+
+

+[RFC8415]で説明されているように、クライアントはトランザクションIDを生成し、この値をトランザクション-IDフィールドに挿入する必要があります。 +

+
+
+
+
+

+The client MUST include the Client Identifier option [RFC8415] in the ADDR-REG-INFORM message. +

+
+
+

+クライアントは、addr-reg-informメッセージにクライアント識別子オプション[RFC8415]を含める必要があります。 +

+
+
+
+
+

+The ADDR-REG-INFORM message MUST NOT contain the Server Identifier option and MUST contain exactly one IA Address option containing the address being registered. The valid-lifetime and preferred-lifetime fields in the option MUST match the current Valid Lifetime and Preferred Lifetime of the address being registered. +

+
+
+

+AddR-Reg-Informメッセージには、サーバー識別子オプションが含まれていない必要があり、登録されているアドレスを含む1つのIAアドレスオプションを正確に含める必要があります。オプション内の有効なリフェティタイムおよび優先ライフタイムフィールドは、登録されているアドレスの現在の有効な寿命と優先寿命と一致する必要があります。 +

+
+
+
+
+

+The ADDR-REG-INFORM message is dedicated for clients to initiate an address registration request toward an address registration server. Consequently, clients MUST NOT put any Option Request option(s) in the ADDR-REG-INFORM message. Clients MAY include other options, such as the Client FQDN option [RFC4704]. +

+
+
+

+Addr-Reg-Informメッセージは、クライアントがアドレス登録要求をアドレス登録サーバーに向けて開始するために専用です。したがって、クライアントはAddR-Reg-Informメッセージにオプションリクエストオプションを配置してはなりません。クライアントには、クライアントFQDNオプション[RFC4704]など、他のオプションが含まれる場合があります。 +

+
+
+
+
+

+The client sends the DHCPv6 ADDR-REG-INFORM message to the All_DHCP_Relay_Agents_and_Servers multicast address (ff02::1:2). The client MUST send separate messages for each address being registered. +

+
+
+

+クライアントは、dhcpv6 addr-reg-informメッセージをAll_dhcp_relay_agents_and_serversマルチキャストアドレス（FF02 :: 1：2）に送信します。クライアントは、登録されているアドレスごとに個別のメッセージを送信する必要があります。 +

+
+
+
+
+

+Unlike other types of messages, which are sent from the link-local address of the client, the ADDR-REG-INFORM message MUST be sent from the address being registered. This is primarily for "fate sharing" purposes; for example, if the network implements some form of Layer 2 security to prevent a client from spoofing other clients' MAC addresses, this prevents an attacker from spoofing ADDR-REG-INFORM messages. +

+
+
+

+クライアントのLink-Localアドレスから送信される他のタイプのメッセージとは異なり、登録されているアドレスからADDR-REG-INFOLTメッセージを送信する必要があります。これは主に「運命共有」の目的のためです。たとえば、ネットワークが何らかの形のレイヤー2セキュリティを実装して、クライアントが他のクライアントのMACアドレスを呼び起こさないようにする場合、攻撃者がAddr-Reg-Informメッセージをスプーフィングすることを防ぎます。 +

+
+
+
+
+

+On clients with multiple interfaces, the client MUST only send the packet on the network interface that has the address being registered, even if it has multiple interfaces with different addresses. If the same address is configured on multiple interfaces, then the client MUST send the ADDR-REG-INFORM message each time the address is configured on an interface that did not previously have it and refresh each registration independently from the others. +

+
+
+

+複数のインターフェイスを備えたクライアントでは、クライアントは、異なるアドレスを持つ複数のインターフェイスがある場合でも、登録されているネットワークインターフェイスにパケットを送信する必要があります。同じアドレスが複数のインターフェイスで構成されている場合、アドレスが以前にそれを持っていなかったインターフェイスで構成され、他の登録を独立して各登録を更新するたびに、クライアントはAddR-Reg-Informメッセージを送信する必要があります。 +

+
+
+
+
+

+The client MUST only send the ADDR-REG-INFORM message for valid addresses [RFC4862] of global scope [RFC4007]. This includes Unique Local Addresses (ULAs), which are defined in [RFC4193] to have global scope. This also includes statically assigned addresses of global scope (such addresses are considered to be valid indefinitely). The client MUST NOT send the ADDR-REG-INFORM message for addresses configured by DHCPv6. +

+
+
+

+クライアントは、グローバルスコープ[RFC4007]の有効なアドレス[RFC4862]に対してAddR-Reg-Informメッセージを送信する必要があります。これには、グローバルな範囲を持つために[RFC4193]で定義されている一意のローカルアドレス（ULAS）が含まれます。これには、グローバルスコープの静的に割り当てられたアドレスも含まれます（このようなアドレスは無期限に有効であると見なされます）。クライアントは、DHCPV6によって構成されたアドレスのADDR-REG-INFOLTメッセージを送信してはなりません。 +

+
+
+
+
+

+The client SHOULD NOT send the ADDR-REG-INFORM message unless it has received a Router Advertisement (RA) message with either the M or O flags set to 1. +

+
+
+

+クライアントは、1に設定されたMまたはOフラグのいずれかを使用してルーター広告（RA）メッセージを受信しない限り、ADDR-REG-INFOLDメッセージを送信しないでください。 +

+
+
+
+
+

+Clients MUST discard any received ADDR-REG-INFORM messages. +

+
+
+

+クライアントは、受信したAddR-Reg-Informメッセージを破棄する必要があります。 +

+
+
+
+
+
+4.2.1. Server Message Processing +
+
+
+
+4.2.1. サーバーメッセージ処理 +
+
+
+
+
+

+Servers MUST discard any ADDR-REG-INFORM messages that meet any of the following conditions: +

+
+
+

+サーバーは、次の条件のいずれかを満たすAddr-Reg-Informメッセージを破棄する必要があります。 +

+
+
+
+
+

+* the message does not include a Client Identifier option; +

+
+
+

+* メッセージには、クライアント識別子オプションは含まれていません。 +

+
+
+
+
+

+* the message includes a Server Identifier option; +

+
+
+

+* メッセージには、サーバー識別子オプションが含まれます。 +

+
+
+
+
+

+* the message does not include the IA Address option, or the IP address in the IA Address option does not match the source address of the original ADDR-REG-INFORM message sent by the client. The source address of the original message is the source IP address of the packet if it is not relayed or is the peer-address field of the innermost Relay-forward message if it is relayed; or +

+
+
+

+* メッセージにはIAアドレスオプションが含まれていません。または、IAアドレスオプションのIPアドレスは、クライアントが送信した元のAddR-Reg-Informメッセージのソースアドレスと一致しません。元のメッセージのソースアドレスは、リレーされていない場合のパケットのソースIPアドレス、またはリレーされている場合の最も内側のリレーフォワードメッセージのピアアドレスフィールドです。または +

+
+
+
+
+

+* the message includes an Option Request option. +

+
+
+

+* メッセージには、オプションリクエストオプションが含まれています。 +

+
+
+
+
+

+If the message is not discarded, the address registration server SHOULD verify that the address being registered is "appropriate to the link" as defined by [RFC8415] or within a prefix delegated to the client via DHCPv6 for Prefix Delegation (DHCPv6-PD) (see Section 6.3 of [RFC8415]). If the address being registered fails this verification, the server MUST drop the message and SHOULD log this fact. If the message passes the verification, the server: +

+
+
+

+メッセージが破棄されていない場合、アドレス登録サーバーは、登録されているアドレスが[RFC8415]で定義されているように「リンクに適している」、またはプレフィックス委任のためにDHCPV6を介してクライアントに委任されたプレフィックス内で「リンクに適している」ことを確認する必要があります（DHCPV6-PD）（[RFC8415]のセクション6.3を参照してください。登録されているアドレスがこの検証に失敗した場合、サーバーはメッセージをドロップする必要があり、この事実を記録する必要があります。メッセージが検証を渡す場合、サーバー： +

+
+
+
+
+

+* MUST log the address registration information (as is done normally for clients to which it has assigned an address), unless it is configured not to do so. The server SHOULD log the client DHCP Unique Identifier (DUID) and the link-layer address, if available. The server MAY log any other information. +

+
+
+

+* アドレス登録情報を記録する必要があります（アドレスを割り当てたクライアントに対して通常行われます）。サーバーは、利用可能な場合は、クライアントDHCP一意の識別子（DUID）とリンク層アドレスを記録する必要があります。サーバーは、他の情報を記録する場合があります。 +

+
+
+
+
+

+* SHOULD register a binding between the provided Client Identifier and IPv6 address in its database, if no binding exists. The lifetime of the binding is equal to the Valid Lifetime of the address reported by the client. If there is already a binding between the registered address and the same client, the server MUST update its lifetime. If there is already a binding between the registered address and another client, the server SHOULD log the fact and update the binding. +

+
+
+

+* バインディングが存在しない場合は、データベースに提供されたクライアント識別子とIPv6アドレスの間にバインディングを登録する必要があります。バインディングの寿命は、クライアントが報告したアドレスの有効な寿命に等しくなります。登録されたアドレスと同じクライアントの間にすでに拘束力がある場合、サーバーはその寿命を更新する必要があります。登録アドレスと別のクライアントの間に既にバインディングがある場合、サーバーは事実を記録し、バインディングを更新する必要があります。 +

+
+
+
+
+

+* SHOULD mark the address as unavailable for use and not include it in future Advertise messages. +

+
+
+

+* アドレスを使用することはできないとマークし、将来の広告メッセージに含めないでください。 +

+
+
+
+
+

+* MUST send back an ADDR-REG-REPLY message to ensure the client does not retransmit. +

+
+
+

+* クライアントが再送信されないようにするために、AddR-Reg-Replyメッセージを送り返す必要があります。 +

+
+
+
+
+

+If a client is multihomed (i.e., connected to multiple administrative domains, each operating its own DHCPv6 infrastructure), the requirement to verify that the registered address is appropriate for the link or belongs to a delegated prefix ensures that each DHCPv6 server only registers bindings for addresses from the given administrative domain. +

+
+
+

+クライアントがマルチホーム（つまり、複数の管理ドメインに接続され、それぞれが独自のDHCPV6インフラストラクチャに接続されている場合）の場合、登録アドレスがリンクに適しているか、委任されたプレフィックスに属していることを確認する要件は、各DHCPV6サーバーのみを保証することを保証します。指定された管理ドメインからのアドレス。 +

+
+
+
+
+

+As mentioned in Section 4.2, although a client "MUST NOT send the ADDR-REG-INFORM message for addresses configured by DHCPv6", if a server does receive such a message, it SHOULD log and discard it. +

+
+
+

+セクション4.2で述べたように、クライアントは「DHCPV6で構成されたアドレスのADDR-REG-INFOLTメッセージを送信してはなりません」が、サーバーがそのようなメッセージを受信した場合、ログと破棄する必要があります。 +

+
+
+
+
+

+DHCPv6 relay agents and switches that relay address registration messages directly from clients MUST include the client's link-layer address in the relayed message using the Client Link-Layer Address option [RFC6939] if they would do so for other DHCPv6 client messages such as Solicit, Request, and Rebind. +

+
+
+

+DHCPV6リレーエージェントとリレーアドレス登録メッセージをクライアントから直接スイッチする必要があります。クライアントリンクレイヤーアドレスオプション[RFC6939]を使用して、クライアントのリンクレイヤーアドレスをリレーしたメッセージに含める必要があります。リクエスト、そして逆にします。 +

+
+
+
+
+
+4.3. DHCPv6 Address Registration Acknowledgement +
+
+
+
+4.3. DHCPV6アドレス登録承認 +
+
+
+
+
+

+The server MUST acknowledge receipt of a valid ADDR-REG-INFORM message by sending back an ADDR-REG-REPLY message. The format of the ADDR-REG-REPLY message is described as follows: +

+
+
+

+サーバーは、addr-reg-replyメッセージを返送して、有効なaddr-reg-informメッセージの受信を確認する必要があります。Addr-Reg-Replyメッセージの形式は、次のように説明されています。 +

+
+
+
+
+ 
+     0                   1                   2                   3
+     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |    msg-type   |               transaction-id                  |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                                                               |
+    .                            options                            .
+    .                           (variable)                          .
+    |                                                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+

+Figure 4: DHCPv6 ADDR-REG-REPLY Message +

+
+
+

+図4：DHCPV6 Addr-Reg-Replyメッセージ +

+
+
+
+
+

+msg-type: +

+
+
+

+MSGタイプ： +

+
+
+
+
+

+Identifies the DHCPv6 message type; set to ADDR-REG-REPLY (37). +

+
+
+

+DHCPV6メッセージタイプを識別します。Addr-Reg-Reply（37）に設定します。 +

+
+
+
+
+

+transaction-id: +

+
+
+

+Transaction-ID： +

+
+
+
+
+

+The transaction ID for this message exchange. +

+
+
+

+このメッセージ交換のトランザクションID。 +

+
+
+
+
+

+options: +

+
+
+

+オプション： +

+
+
+
+
+

+The options carried in this message. +

+
+
+

+このメッセージに掲載されたオプション。 +

+
+
+
+
+

+If the ADDR-REG-INFORM message that the server is replying to was not relayed, then the IPv6 destination address of the message MUST be the address being registered. If the ADDR-REG-INFORM message was relayed, then the server MUST construct the Relay-reply message as specified in Section 19.3 of [RFC8415]. +

+
+
+

+サーバーが返信しているAddR-Reg-Informメッセージが中継されていない場合、メッセージのIPv6宛先アドレスは登録されているアドレスでなければなりません。addr-reg-informメッセージがリレーされた場合、[RFC8415]のセクション19.3で指定されているように、サーバーはリレー無応メッセージを構築する必要があります。 +

+
+
+
+
+

+The server MUST copy the transaction-id from the ADDR-REG-INFORM message to the transaction-id field of the ADDR-REG-REPLY. +

+
+
+

+サーバーは、Transaction-IDをADDR-REG-INFORMメッセージからAddR-Reg-ReplyのトランザクションIDフィールドにコピーする必要があります。 +

+
+
+
+
+

+The ADDR-REG-REPLY message MUST contain an IA Address option for the address being registered. The option MUST be identical to the one in the ADDR-REG-INFORM message that the server is replying to. +

+
+
+

+AddR-Reg-Replyメッセージには、登録されているアドレスのIAアドレスオプションを含める必要があります。このオプションは、サーバーが返信しているAddr-Reg-Informメッセージのものと同一でなければなりません。 +

+
+
+
+
+

+Servers MUST ignore any received ADDR-REG-REPLY messages. +

+
+
+

+サーバーは、受信したAddR-Reg-Replyメッセージを無視する必要があります。 +

+
+
+
+
+

+Clients MUST discard any ADDR-REG-REPLY messages that meet any of the following conditions: +

+
+
+

+クライアントは、次の条件のいずれかを満たすADDR-REGREPLYメッセージを破棄する必要があります。 +

+
+
+
+
+

+* the IPv6 destination address does not match the address being registered; +

+
+
+

+* IPv6宛先アドレスは、登録されているアドレスと一致しません。 +

+
+
+
+
+

+* the IA Address option does not match the address being registered; +

+
+
+

+* IAアドレスオプションは、登録されているアドレスと一致しません。 +

+
+
+
+
+

+* the address being registered is not assigned to the interface receiving the message; or +

+
+
+

+* 登録されているアドレスは、メッセージを受信するインターフェイスに割り当てられていません。または +

+
+
+
+
+

+* the transaction-id does not match the transaction-id the client used in the corresponding ADDR-REG-INFORM message. +

+
+
+

+* Transaction-IDは、クライアントが対応するAddR-Reg-Informメッセージで使用したトランザクションIDと一致しません。 +

+
+
+
+
+

+The ADDR-REG-REPLY message only indicates that the ADDR-REG-INFORM message has been received and that the client should not retransmit it. The ADDR-REG-REPLY message MUST NOT be considered to be any indication of the address validity and MUST NOT be required for the address to be usable. DHCPv6 relays, or other devices that snoop ADDR-REG-REPLY messages, MUST NOT add or alter any forwarding or security state based on the ADDR-REG-REPLY message. +

+
+
+

+Addr-Reg-Replyメッセージは、Addr-Reg-Informメッセージが受信され、クライアントがそれを再送信してはならないことを示しています。Addr-Reg-Replyメッセージは、アドレスの有効性の兆候であると見なされてはなりません。また、アドレスを使用できるようにするには必須であってはなりません。DHCPV6リレー、またはAddR-Reg-ReplyメッセージをSnoopである他のデバイスは、AddR-Reg-Replyメッセージに基づいて転送またはセキュリティ状態を追加または変更してはなりません。 +

+
+
+
+
+
+4.4. Signaling Address Registration Support +
+
+
+
+4.4. シグナリングアドレス登録サポート +
+
+
+
+
+

+To avoid undesired multicast traffic, the client MUST NOT register addresses using this mechanism unless the DHCPv6 infrastructure supports address registration. The client can discover this by including the OPTION_ADDR_REG_ENABLE option in the Option Request options that it sends. If the client receives and processes an Advertise or Reply message with the OPTION_ADDR_REG_ENABLE option, it concludes that the DHCPv6 infrastructure supports address registration. When the client detects address registration support, it MUST start the registration process (unless configured not to do so) and MUST immediately register any addresses that are already in use. Once the client starts the registration process, it MUST NOT stop registering addresses until it disconnects from the link, even if subsequent Advertise or Reply messages do not contain the OPTION_ADDR_REG_ENABLE option. +

+
+
+

+望ましくないマルチキャストトラフィックを回避するために、DHCPV6インフラストラクチャがアドレス登録をサポートしていない限り、クライアントはこのメカニズムを使用してアドレスを登録してはなりません。クライアントは、送信するオプションリクエストオプションにoption_addr_reg_enableオプションを含めることでこれを発見できます。クライアントがOption_Addr_Reg_Enableオプションを使用して広告または返信メッセージを受信および処理する場合、DHCPV6インフラストラクチャがアドレス登録をサポートしていると結論付けます。クライアントがアドレス登録サポートを検出した場合、登録プロセスを開始する必要があります（そうしないように構成されていない限り）。既に使用されているアドレスをすぐに登録する必要があります。クライアントが登録プロセスを開始したら、後続の広告または返信メッセージにoption_addr_reg_enableオプションが含まれていない場合でも、リンクから切断されるまでアドレスの登録を停止しないでください。 +

+
+
+
+
+

+The client MUST discover whether the DHCPv6 infrastructure supports address registration every time it connects to a network or when it detects it has moved to a new link, without utilizing any prior knowledge about address registration support on that network or link. This client behavior allows networks to progressively roll out support for the Address Registration option across the DHCPv6 infrastructure without causing clients to frequently stop and restart address registration if some of the network's DHCPv6 servers support it and some do not. +

+
+
+

+クライアントは、DHCPV6インフラストラクチャがネットワークに接続するたびにアドレス登録をサポートしているかどうか、またはそのネットワークまたはリンクのアドレス登録サポートに関する事前知識を利用せずに、新しいリンクに移動した場合に住所登録をサポートするかどうかを発見する必要があります。このクライアントの動作により、ネットワークのDHCPV6サーバーの一部がサポートしていない場合、クライアントが頻繁に停止し、アドレス登録を再起動することなく、DHCPV6インフラストラクチャ全体のアドレス登録オプションのサポートを徐々にロールアウトできます。 +

+
+
+
+
+

+A client with multiple interfaces MUST discover address registration support for each interface independently. The client MUST NOT send address registration messages on a given interface unless the client has discovered that the interface is connected to a network that supports address registration. +

+
+
+

+複数のインターフェイスを備えたクライアントは、各インターフェイスのアドレス登録サポートを個別に発見する必要があります。クライアントは、インターフェイスがアドレス登録をサポートするネットワークに接続されていることをクライアントが発見しない限り、特定のインターフェイスにアドレス登録メッセージを送信してはなりません。 +

+
+
+
+
+
+4.5. Retransmission +
+
+
+
+4.5. 再送信 +
+
+
+
+
+

+To reduce the effects of packet loss on registration, the client MUST retransmit the registration message. Retransmissions SHOULD follow the standard retransmission logic specified by Section 15 of [RFC8415] with the following default parameters for the initial retransmission time (IRT) and maximum retransmission count (MRC): +

+
+
+

+登録に対するパケット損失の影響を減らすために、クライアントは登録メッセージを再送信する必要があります。再送信は、[RFC8415]のセクション15で指定された標準の再送信ロジックに従って、初期再送信時間（IRT）および最大再送信数（MRC）の次のデフォルトパラメーターを使用する必要があります。 +

+
+
+
+
+

+* IRT 1 sec +

+
+
+

+* IRT 1秒 +

+
+
+
+
+

+* MRC 3 +

+
+
+

+* MRC 3 +

+
+
+
+
+

+The client SHOULD allow these parameters to be configured by the administrator. +

+
+
+

+クライアントは、これらのパラメーターを管理者によって構成することを許可する必要があります。 +

+
+
+
+
+

+To comply with Section 16.1 of [RFC8415], the client MUST leave the transaction ID unchanged in retransmissions of an ADDR-REG-INFORM message. When the client retransmits the registration message, the lifetimes in the packet MUST be updated so that they match the current lifetimes of the address. +

+
+
+

+[RFC8415]のセクション16.1に準拠するには、クライアントは、AddR-Reg-Informメッセージの再送信に変更されていないままにしておく必要があります。クライアントが登録メッセージを再送信するとき、パケットの寿命を更新して、アドレスの現在の寿命と一致するようにする必要があります。 +

+
+
+
+
+

+If an ADDR-REG-REPLY message is received for the address being registered, the client MUST stop retransmission. +

+
+
+

+登録されているアドレスに対してADDR-REGREPLYメッセージが受信された場合、クライアントは再送信を停止する必要があります。 +

+
+
+
+
+
+4.6. Registration Expiry and Refresh +
+
+
+
+4.6. 登録の有効期限と更新 +
+
+
+
+
+

+The client MUST refresh registrations to ensure that the server is always aware of which addresses are still valid. The client SHOULD perform refreshes as described below. +

+
+
+

+クライアントは、サーバーが常に有効であることをサーバーが常に認識していることを確認するために登録を更新する必要があります。クライアントは、以下に説明するようにリフレッシュを実行する必要があります。 +

+
+
+
+
+
+4.6.1. SLAAC Addresses +
+
+
+
+4.6.1. SLAACアドレス +
+
+
+
+
+

+For an address configured using SLAAC, a function AddrRegRefreshInterval(address) is defined as 80% of the address's current Valid Lifetime. When calculating this value, the client applies a multiplier of AddrRegDesyncMultiplier to avoid synchronization with other clients, which could cause a large number of registration messages to reach the server at the same time. AddrRegDesyncMultiplier is a random value uniformly distributed between 0.9 and 1.1 (inclusive) and is chosen by the client when it starts the registration process, to ensure that refreshes for addresses with the same lifetime are coalesced (see below). +

+
+
+

+SLAACを使用して構成されたアドレスの場合、関数addRregrefreshinterval（アドレス）は、アドレスの現在の有効な寿命の80％として定義されます。この値を計算するとき、クライアントは他のクライアントとの同期を避けるためにAddRregdesyncMultiplierの乗数を適用します。AddRregdesyncMultiplierは、0.9から1.1（包括的）の間に均一に分布したランダムな値であり、登録プロセスを開始するときにクライアントによって選択され、同じ寿命の住所のリフレッシュが合体されていることを確認します（以下を参照）。 +

+
+
+
+
+

+Whenever the client registers or refreshes an address, it calculates a NextAddrRegRefreshTime for that address as AddrRegRefreshInterval seconds in the future but does not schedule any refreshes. +

+
+
+

+クライアントがアドレスを登録またはリフレッシュするたびに、そのアドレスのnextddrregrefreshtimeを将来addRregrefreshinterval秒として計算しますが、リフレッシュをスケジュールしません。 +

+
+
+
+
+

+Whenever the network changes the Valid Lifetime of an existing address by more than 1%, for example, by sending a Prefix Information Option (PIO) [RFC4861] with a new Valid Lifetime, the client calculates a new AddrRegRefreshInterval. The client schedules a refresh for min(now + AddrRegRefreshInterval, NextAddrRegRefreshTime). If the refresh would be scheduled in the past, then the refresh occurs immediately. +

+
+
+

+ネットワークが既存のアドレスの有効な寿命を1％以上変更するときはいつでも、たとえば、新しい有効な寿命でプレフィックス情報オプション（PIO）[RFC4861]を送信することにより、クライアントは新しいAddRregrefreshintervalを計算します。クライアントはMinの更新をスケジュールします（Now + AddRregrefreshinterval、NextDdrregrefreshtime）。過去に更新がスケジュールされる場合、更新はすぐに発生します。 +

+
+
+
+
+

+Justification: This algorithm ensures that refreshes are not sent too frequently while ensuring that the server never believes that the address has expired when it has not. Specifically, after every registration: +

+
+
+

+正当化：このアルゴリズムは、リフレッシュがあまり頻繁に送信されないことを保証しますが、サーバーが住所がないときに期限切れになっていると信じていないことを保証します。具体的には、すべての登録の後： +

+
+
+
+
+

+* If the network never changes the lifetime of an address (e.g., if no further PIOs are received, or if all PIO lifetimes decrease in step with the passage of time), then no refreshes occur. Refreshes are not necessary, because the address expires at the time the server expects it to expire. +

+
+
+

+* ネットワークがアドレスの寿命を変更しない場合（たとえば、それ以上のPIOが受信されない場合、またはすべてのPIO寿命が時間の経過とともにステップが減少する場合）、リフレッシュは発生しません。サーバーが期限切れになると予想している時点でアドレスの有効期限が切れるため、リフレッシュは必要ありません。 +

+
+
+
+
+

+* Any time the network changes the lifetime of an address (i.e., changes the time at which the address will expire), the client ensures that a refresh is scheduled, so that server will be informed of the new expiry. +

+
+
+

+* ネットワークがアドレスの寿命を変更すると（つまり、アドレスが期限切れになる時間を変更します）、クライアントは更新がスケジュールされることを保証し、サーバーに新しい有効期限を通知します。 +

+
+
+
+
+

+* Because AddrRegDesyncMultiplier is at most 1.1, the refresh never occurs later than a point 88% between the time when the address was registered and the time when the address will expire. This allows the client to retransmit the registration for up to 12% of the original interval before it expires. This may not be possible if the network sends a Router Advertisement (RA) [RFC4861] very close to the time when the address would have expired. In this case, the client refreshes immediately, which is the best it can do. +

+
+
+

+* AddRregdesyncMultiplierは最大1.1であるため、住所が登録された時からアドレスが期限切れになるまでの間に、リフレッシュはポイント88％よりも遅くなることはありません。これにより、クライアントは有効期限が切れる前に元の間隔の最大12％の登録を再送信できます。これは、ネットワークがルーター広告（RA）[RFC4861]を送信して、アドレスの有効期限が切れていた場合には不可能です。この場合、クライアントはすぐにリフレッシュしますが、これはできる最善です。 +

+
+
+
+
+

+* The 1% tolerance ensures that the client will not refresh or reschedule refreshes if the Valid Lifetime experiences minor changes due to transmission delays or clock skew between the client and the router(s) sending the RA. +

+
+
+

+* 1％の耐性により、有効な寿命がクライアントとルーターがRAを送信するルーターの間の伝送の遅延または時計歪みのために軽微な変更を経験した場合、クライアントが更新または再スケジュールを再スケジュールしないようにします。 +

+
+
+
+
+

+* AddrRegRefreshCoalesce (Section 4.6.3) allows battery-powered clients to wake up less often. In particular, it allows the client to coalesce refreshes for multiple addresses formed from the same prefix, such as the stable and privacy addresses. Higher values will result in fewer wakeups but may result in more network traffic, because if a refresh is sent early, then the next RA received will cause the client to immediately send a refresh message. +

+
+
+

+* AddRregrefreshcoalesce（セクション4.6.3）により、バッテリー駆動のクライアントは頻繁に目を覚ますことができます。特に、クライアントは、安定したアドレスやプライバシーアドレスなど、同じプレフィックスから形成された複数のアドレスのリフレッシュを合体化できます。値が高いとウェイクアップが少なくなりますが、ネットワークトラフィックが増える可能性があります。これは、更新が早めに送信された場合、次のRAが受信するとクライアントがすぐに更新メッセージを送信するためです。 +

+
+
+
+
+

+* In typical networks, the lifetimes in periodic RAs either contain constant values or values that decrease over time to match another lifetime, such as the lifetime of a prefix delegated to the network. In both these cases, this algorithm will refresh on the order of once per address lifetime, which is similar to the number of refreshes that are necessary using stateful DHCPv6. +

+
+
+

+* 典型的なネットワークでは、周期的なRAの寿命には、ネットワークに委任されたプレフィックスの寿命など、一定の寿命と一致する一定の値または値が含まれています。どちらの場合も、このアルゴリズムは、アドレスごとのライフタイムごとに1回の順序で更新されます。これは、Stateful DHCPV6を使用して必要なリフレッシュの数に似ています。 +

+
+
+
+
+

+* Because refreshes occur at least once per address lifetime, the network administrator can control the address refresh frequency by appropriately setting the Valid Lifetime in the PIO. +

+
+
+

+* リフレッシュはアドレスの寿命ごとに少なくとも1回発生するため、ネットワーク管理者は、PIOで有効な寿命を適切に設定することにより、アドレスの更新周波数を制御できます。 +

+
+
+
+
+
+4.6.2. Statically Assigned Addresses +
+
+
+
+4.6.2. 静的に割り当てられたアドレス +
+
+
+
+
+

+A statically assigned address has an infinite Valid Lifetime that is not affected by RAs. Therefore, whenever the client registers or refreshes a statically assigned address, the next refresh is scheduled for StaticAddrRegRefreshInterval seconds in the future. The default value of StaticAddrRegRefreshInterval is 4 hours. This ensures static addresses are still refreshed periodically, but refreshes for static addresses do not cause excessive multicast traffic. The StaticAddrRegRefreshInterval interval SHOULD be configurable. +

+
+
+

+静的に割り当てられたアドレスには、RASの影響を受けない無限の有効な寿命があります。したがって、クライアントが静的に割り当てられたアドレスを登録または更新するたびに、次の更新は将来のstaticAddrregrefreshintervalの秒にスケジュールされます。StaticAddrregrefreshintervalのデフォルト値は4時間です。これにより、静的アドレスが定期的に更新されるようになりますが、静的アドレスのリフレッシュは過度のマルチキャストトラフィックを引き起こしません。staticAddrregrefreshinterval間の間隔は構成可能である必要があります。 +

+
+
+
+
+
+4.6.3. Transmitting Refreshes +
+
+
+
+4.6.3. 送信リフレッシュ +
+
+
+
+
+

+When a refresh is performed, the client MAY refresh all addresses assigned to the interface that are scheduled to be refreshed within the next AddrRegRefreshCoalesce seconds. The value of AddrRegRefreshCoalesce is implementation dependent, and a suggested default is 60 seconds. +

+
+
+

+更新が実行されると、クライアントは、次のaddRregrefreshcoalesce秒以内に更新される予定のインターフェイスに割り当てられたすべてのアドレスを更新できます。AddRregrefreshcoalesceの値は実装に依存しており、提案されたデフォルトは60秒です。 +

+
+
+
+
+

+Registration refresh packets MUST be retransmitted using the same logic as used for initial registrations (see Section 4.5). +

+
+
+

+登録更新パケットは、初期登録に使用されるのと同じロジックを使用して再送信する必要があります（セクション4.5を参照）。 +

+
+
+
+
+

+The client MUST generate a new transaction ID when refreshing the registration. +

+
+
+

+クライアントは、登録を更新するときに新しいトランザクションIDを生成する必要があります。 +

+
+
+
+
+

+When a Client-Identifier-to-IPv6-address binding expires, the server MUST remove it and consider the address as available for use. +

+
+
+

+クライアントIdentifier-to-IPV6-Addressバインディングバインディングの有効期限が切れる場合、サーバーはそれを削除し、住所を使用できると考える必要があります。 +

+
+
+
+
+

+The client MAY choose to notify the server when an address is no longer being used (e.g., if the client is disconnecting from the network, the address lifetime expired, or the address is being removed from the interface). To indicate that the address is not being used anymore, the client MUST set the preferred-lifetime and valid-lifetime fields of the IA Address option in the ADDR-REG-INFORM message to zero. If the server receives a message with a valid-lifetime of zero, it MUST act as if the address has expired. +

+
+
+

+クライアントは、アドレスが使用されなくなったときにサーバーに通知することを選択できます（たとえば、クライアントがネットワークから切断されている場合、アドレスの寿命が切れる場合、またはアドレスがインターフェイスから削除されています）。アドレスがもはや使用されていないことを示すには、クライアントは、addr-reg-informメッセージにzeroにaddr-reg-informメッセージで、IAアドレスオプションの優先標準時および有効なリフェティタイムフィールドを設定する必要があります。サーバーが有効なゼロのメッセージを受信した場合、アドレスの有効期限が切れているかのように動作する必要があります。 +

+
+
+
+
+
+5. Client Configuration +
+
+
+
+5. クライアント構成 +
+
+
+
+
+

+DHCP clients SHOULD allow the administrator to disable sending ADDR-REG-INFORM messages. Sending the messages SHOULD be enabled by default. +

+
+
+

+DHCPクライアントは、管理者がAddr-Reg-Informメッセージの送信を無効にすることを許可する必要があります。メッセージの送信はデフォルトで有効にする必要があります。 +

+
+
+
+
+
+6. Security Considerations +
+
+
+
+6. セキュリティに関する考慮事項 +
+
+
+
+
+

+An attacker may attempt to register a large number of addresses in quick succession in order to overwhelm the address registration server and/or fill up log files. Similar attack vectors exist today, e.g., an attacker can DoS the server with messages containing spoofed DHCP Unique Identifiers (DUIDs) [RFC8415]. +

+
+
+

+攻撃者は、アドレス登録サーバーを圧倒したり、ログファイルを埋めるために、多数のアドレスを迅速に連続して登録しようとする場合があります。同様の攻撃ベクトルが今日存在します。たとえば、攻撃者は、スプーフィングされたDHCP一意の識別子（DUIDS）を含むメッセージを使用してサーバーをDOSすることができます[RFC8415]。 +

+
+
+
+
+

+If a network is using First-Come, First-Served Source Address Validation Improvement (FCFS SAVI) [RFC6620], then the DHCPv6 server can trust that the ADDR-REG-INFORM message was sent by the legitimate holder of the address. This prevents a client from registering an address configured on another client. +

+
+
+

+ネットワークがファーストカムの最初のソースアドレス検証改善（FCFS SAVI）[RFC6620]を使用している場合、DHCPV6サーバーは、アドレスの正当な所有者によってAddR-Reg-Informメッセージが送信されたことを信頼できます。これにより、クライアントが別のクライアントで構成されたアドレスを登録することができなくなります。 +

+
+
+
+
+

+One of the use cases for the mechanism described in this document is to identify sources of malicious traffic after the fact. Note, however, that as the device itself is responsible for informing the DHCPv6 server that it is using an address, a malicious or compromised device can simply choose to not send the ADDR-REG-INFORM message. This is an informational, optional mechanism and is designed to aid in troubleshooting and forensics. On its own, it is not intended to be a strong security access mechanism. In particular, the ADDR-REG-INFORM message MUST NOT be used for authentication and authorization purposes, because in addition to the reasons above, the packets containing the message may be dropped. +

+
+
+

+このドキュメントで説明されているメカニズムのユースケースの1つは、事実の後に悪意のあるトラフィックの原因を特定することです。ただし、デバイス自体がアドレスを使用していることをDHCPV6サーバーに通知する責任があるため、悪意のあるデバイスまたは侵害されたデバイスは、AddR-Reg-Informメッセージを送信しないことを選択できます。これは情報提供のオプションのメカニズムであり、トラブルシューティングとフォレンジックを支援するように設計されています。それだけでは、強力なセキュリティアクセスメカニズムになることを意図したものではありません。特に、上記の理由に加えて、メッセージを含むパケットが削除される可能性があるため、AddR-Reg-Informメッセージを認証と承認の目的に使用する必要はありません。 +

+
+
+
+
+
+7. Privacy Considerations +
+
+
+
+7. プライバシーに関する考慮事項 +
+
+
+
+
+

+If the network doesn't have Multicast Listener Discovery (MLD) snooping enabled, then IPv6 link-local multicast traffic is effectively transmitted as broadcast. In such networks, an on-link attacker listening to DHCPv6 messages might obtain information about IPv6 addresses assigned to the client. As ADDR-REG-INFORM messages contain unique identifiers such as the client's DUID, the attacker may be able to track addresses being registered and map them to the same client, even if the client uses randomized MAC addresses. This privacy consideration is not specific to the proposed mechanism. Section 4.3 of [RFC7844] discusses using the DUID for device tracking in DHCPv6 environments and provides mitigation recommendations. +

+
+
+

+ネットワークにマルチキャストリスナーディスカバリー（MLD）スヌーピングが有効になっていない場合、IPv6 Link-Local Multicastトラフィックは放送として効果的に送信されます。このようなネットワークでは、DHCPV6メッセージを聞くリンク攻撃者がクライアントに割り当てられたIPv6アドレスに関する情報を取得する場合があります。AddR-Reg-Informメッセージには、クライアントのDUIDなどの一意の識別子が含まれているため、攻撃者は、クライアントがランダム化されたMACアドレスを使用していても、登録されているアドレスを追跡して同じクライアントにマッピングできる場合があります。このプライバシーの考慮は、提案されたメカニズムに固有のものではありません。[RFC7844]のセクション4.3は、DHCPV6環境でのデバイス追跡にDUIDを使用して、緩和の推奨事項を提供します。 +

+
+
+
+
+

+In general, hiding information about the specific IPv6 address from on-link observers should not be considered a security measure, as such information is usually disclosed via Duplicate Address Detection [RFC4862] to all nodes anyway, if MLD snooping is not enabled. +

+
+
+

+一般に、MLDスヌーピングが有効になっていない場合、とにかくすべてのノードにそのような情報が開示されるため、そのような情報は通常、そのような情報がすべてのノードに開示されるため、リンクオンオブザーバーからの特定のIPv6アドレスに関する情報を隠すことはセキュリティ尺度と見なされるべきではありません。 +

+
+
+
+
+

+If MLD snooping is enabled, an attacker might be able to join the All_DHCP_Relay_Agents_and_Servers multicast address (ff02::1:2) group to listen for address registration messages. However, the same result can be achieved by joining the All Routers Address (ff02::2) group and listen to gratuitous neighbor advertisement messages [RFC9131]. It should be noted that this particular scenario shares the fate with DHCPv6 address assignment: if an attacker can join the All_DHCP_Relay_Agents_and_Servers multicast group, they would be able to monitor all DHCPv6 messages sent from the client to DHCPv6 servers and relays and therefore obtain the information about addresses being assigned via DHCPv6. Layer 2 isolation allows mitigating this threat by blocking on-link peer-to-peer communication between nodes. +

+
+
+

+MLDスヌーピングが有効になっている場合、攻撃者はALL_DHCP_RELAY_AGENTS_AND_SERVERS MULTICASTアドレス（FF02 :: 1：2）グループに参加してアドレス登録メッセージを聞くことができる場合があります。ただし、すべてのルーターアドレス（FF02 :: 2）グループに参加して、無償の近隣広告メッセージ[RFC9131]を聴くことで、同じ結果を達成できます。この特定のシナリオは、DHCPV6アドレスの割り当てと運命を共有していることに注意してください。攻撃者がALL_DHCP_RELAY_AGENTS_AND_SERVERS MULTICASTグループに参加できる場合、クライアントからDHCPV6セルバーとリレーとリレーのすべてのDHCPV6メッセージを監視し、情報を入手できます。DHCPV6を介して割り当てられているアドレス。レイヤー2の分離により、ノード間のオンリンクピアツーピア通信をブロックすることにより、この脅威を軽減できます。 +

+
+
+
+
+
+8. IANA Considerations +
+
+
+
+8. IANAの考慮事項 +
+
+
+
+
+

+This document introduces the following entities, which have been allocated in the "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry group defined at <http://www.iana.org/assignments/ dhcpv6-parameters>. These include: +

+
+
+

+このドキュメントでは、次のエンティティを紹介します。これらのエンティティは、<http://www.iana.org/assignments/ dhcpv6-parameters>で定義されている「IPv6（dhcpv6）の動的ホスト構成プロトコル」レジストリグループに割り当てられています。これらには以下が含まれます： +

+
+
+
+
+

+* One new DHCPv6 option, described in Section 4.1, which has been allocated in the "Option Codes" registry: +

+
+
+

+* セクション4.1で説明されている1つの新しいDHCPV6オプション。「オプションコード」レジストリで割り当てられています。 +

+
+
+
+
+

+Value: +

+
+
+

+値： +

+
+
+
+
+

+148 +

+
+
+

+148 +

+
+
+
+
+

+Description: +

+
+
+

+説明： +

+
+
+
+
+

+OPTION_ADDR_REG_ENABLE +

+
+
+

+option_addr_reg_enable +

+
+
+
+
+

+Client ORO: +

+
+
+

+クライアントORO： +

+
+
+
+
+

+Yes +

+
+
+

+はい +

+
+
+
+
+

+Singleton Option: +

+
+
+

+シングルトンオプション： +

+
+
+
+
+

+Yes +

+
+
+

+はい +

+
+
+
+
+

+Reference: +

+
+
+

+参照： +

+
+
+
+
+

+RFC 9686 +

+
+
+

+RFC 9686 +

+
+
+
+
+

+* Two new DHCPv6 messages, which have been allocated in the "Message Types" registry (for more information, see Sections 4.2 and 4.3, respectively, for each DHCPv6 message): +

+
+
+

+* 「メッセージタイプ」レジストリに割り当てられている2つの新しいDHCPV6メッセージ（詳細については、それぞれDHCPV6メッセージごとにセクション4.2と4.3を参照）を参照してください）： +

+
+
+
+
+

+Value: +

+
+
+

+値： +

+
+
+
+
+

+36 +

+
+
+

+36 +

+
+
+
+
+

+Description: +

+
+
+

+説明： +

+
+
+
+
+

+ADDR-REG-INFORM +

+
+
+

+addr-reg-inform +

+
+
+
+
+

+Reference: +

+
+
+

+参照： +

+
+
+
+
+

+RFC 9686 +

+
+
+

+RFC 9686 +

+
+
+
+
+

+Value: +

+
+
+

+値： +

+
+
+
+
+

+37 +

+
+
+

+37 +

+
+
+
+
+

+Description: +

+
+
+

+説明： +

+
+
+
+
+

+ADDR-REG-REPLY +

+
+
+

+Addr-Reg-Reply +

+
+
+
+
+

+Reference: +

+
+
+

+参照： +

+
+
+
+
+

+RFC 9686 +

+
+
+

+RFC 9686 +

+
+
+
+
+
+9. References +
+
+
+
+9. 参考文献 +
+
+
+
+
+
+9.1. Normative References +
+
+
+
+9.1. 引用文献 +
+
+
+
+
+ 
+   [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>.
+
+
+
+
+
+ 
+   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
+              RFC 2131, DOI 10.17487/RFC2131, March 1997,
+              <https://www.rfc-editor.org/info/rfc2131>.
+
+
+
+
+
+ 
+   [RFC4007]  Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
+              B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
+              DOI 10.17487/RFC4007, March 2005,
+              <https://www.rfc-editor.org/info/rfc4007>.
+
+
+
+
+
+ 
+   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
+              Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
+              <https://www.rfc-editor.org/info/rfc4193>.
+
+
+
+
+
+ 
+   [RFC4704]  Volz, B., "The Dynamic Host Configuration Protocol for
+              IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
+              Option", RFC 4704, DOI 10.17487/RFC4704, October 2006,
+              <https://www.rfc-editor.org/info/rfc4704>.
+
+
+
+
+
+ 
+   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
+              Address Autoconfiguration", RFC 4862,
+              DOI 10.17487/RFC4862, September 2007,
+              <https://www.rfc-editor.org/info/rfc4862>.
+
+
+
+
+
+ 
+   [RFC6939]  Halwasia, G., Bhandari, S., and W. Dec, "Client Link-Layer
+              Address Option in DHCPv6", RFC 6939, DOI 10.17487/RFC6939,
+              May 2013, <https://www.rfc-editor.org/info/rfc6939>.
+
+
+
+
+
+ 
+   [RFC7844]  Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
+              Profiles for DHCP Clients", RFC 7844,
+              DOI 10.17487/RFC7844, May 2016,
+              <https://www.rfc-editor.org/info/rfc7844>.
+
+
+
+
+
+ 
+   [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>.
+
+
+
+
+
+ 
+   [RFC8415]  Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
+              Richardson, M., Jiang, S., Lemon, T., and T. Winters,
+              "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
+              RFC 8415, DOI 10.17487/RFC8415, November 2018,
+              <https://www.rfc-editor.org/info/rfc8415>.
+
+
+
+
+
+ 
+   [RFC9131]  Linkova, J., "Gratuitous Neighbor Discovery: Creating
+              Neighbor Cache Entries on First-Hop Routers", RFC 9131,
+              DOI 10.17487/RFC9131, October 2021,
+              <https://www.rfc-editor.org/info/rfc9131>.
+
+
+
+
+
+
+9.2. Informative References +
+
+
+
+9.2. 参考引用 +
+
+
+
+
+ 
+   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
+              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
+              DOI 10.17487/RFC4861, September 2007,
+              <https://www.rfc-editor.org/info/rfc4861>.
+
+
+
+
+
+ 
+   [RFC6620]  Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS
+              SAVI: First-Come, First-Served Source Address Validation
+              Improvement for Locally Assigned IPv6 Addresses",
+              RFC 6620, DOI 10.17487/RFC6620, May 2012,
+              <https://www.rfc-editor.org/info/rfc6620>.
+
+
+
+
+
+
+Acknowledgements +
+
+
+
+謝辞 +
+
+
+
+
+

+Many thanks to Bernie Volz for the significant review and feedback, as well as Hermin Anggawijaya, Carlos Jesus Bernardos, Brian Carpenter, Stuart Cheshire, Roman Danyliw, Alan DeKok, James Guichard, James Guichard, Erik Kline, Mallory Knodel, Murray Kucherawy, David Lamparter, Ted Lemon, Eric Levy-Abegnoli, Aditi Patange, Jim Reid, Michael Richardson, Patrick Rohr, John Scudder, Mark Smith, Gunter Van de Velde, Eric Vyncke, Timothy Winters, and Peter Yee for their feedback, comments, and guidance. We apologize if we inadvertently forgot to acknowledge anyone's contributions. +

+
+
+

+重要なレビューとフィードバック、ハーミンアンガウィジャヤ、カルロスジーザスバーナルドス、ブライアンカーペンター、スチュアートチェシャー、スチュアートチェシャー、ローマンダニリウ、アランデコック、ジェームズギチャード、ジェームズギチャード、エリッククライン、マロリーノードル、マレークエラウィー、デイビッド、デイビッドランパター、テッド・レモン、エリック・レヴィー・アベグノリ、アディティ・パターンジ、ジム・リード、マイケル・リチャードソン、パトリック・ローア、ジョン・スカダー、マーク・スミス、ガンター・ヴァン・デ・ヴェルデ、エリック・ヴィンケ、タイムシー・ウィンターズ、ピーター・イーのフィードバック、コメント、指導のためにピーター・イー。誰の貢献を認めるのを不注意に忘れてしまったことをお詫びします。 +

+
+
+
+
+
+Contributors +
+
+
+
+貢献者 +
+
+
+
+
+ 
+   Gang Chen
+   China Mobile
+   53A, Xibianmennei Ave.
+   Xuanwu District
+   Beijing
+   China
+   Email: phdgang@gmail.com
+
+
+
+
+
+
+Authors' Addresses +
+
+
+
+著者のアドレス +
+
+
+
+
+ 
+   Warren Kumari
+   Google, LLC
+   Email: warren@kumari.net
+
+
+
+
+
+ 
+   Suresh Krishnan
+   Cisco Systems, Inc.
+   Email: suresh.krishnan@gmail.com
+
+
+
+
+
+ 
+   Rajiv Asati
+   Independent
+   Email: rajiv.asati@gmail.com
+
+
+
+
+
+ 
+   Lorenzo Colitti
+   Google, LLC
+   Shibuya 3-21-3,
+   Japan
+   Email: lorenzo@google.com
+
+
+
+
+
+ 
+   Jen Linkova
+   Google, LLC
+   1 Darling Island Rd
+   Pyrmont  2009
+   Australia
+   Email: furry13@gmail.com
+
+
+
+
+
+ 
+   Sheng Jiang
+   Beijing University of Posts and Telecommunications
+   No. 10 Xitucheng Road
+   Beijing
+   Haidian District, 100083
+   China
+   Email: shengjiang@bupt.edu.cn
+
+
+
+
+ + + diff --git a/html/rfc9689.html b/html/rfc9689.html new file mode 100644 index 000000000..5689d2531 --- /dev/null +++ b/html/rfc9689.html @@ -0,0 +1,4915 @@ + + + + + + RFC 9689 - Use Cases for a PCE as a Central Controller (PCECC) 日本語訳 + + + + + + + + + + + + +
+
+ + + +
+
+
+ + +
+
+
+ 
+Internet Engineering Task Force (IETF)                             Z. Li
+Request for Comments: 9689                                      D. Dhody
+Category: Informational                              Huawei Technologies
+ISSN: 2070-1721                                                  Q. Zhao
+                                                        Etheric Networks
+                                                                   K. He
+                                                   Tencent Holdings Ltd.
+                                                             B. Khasanov
+                                                  MTS Web Services (MWS)
+                                                           December 2024
+
+
+
+
+
+
+Use Cases for a PCE as a Central Controller (PCECC) +
+
+
+
+中央コントローラーとしてのPCEのユースケース（PCECC） +
+
+
+
+
+
+Abstract +
+
+
+
+概要 +
+
+
+
+
+

+The PCE is a core component of a Software-Defined Networking (SDN) system. It can be used to compute optimal paths for network traffic and update existing paths to reflect changes in the network or traffic demands. The PCE was developed to derive Traffic Engineering (TE) paths in MPLS networks, which are supplied to the headend of the paths using the Path Computation Element Communication Protocol (PCEP). +

+
+
+

+PCEは、ソフトウェア定義ネットワーク（SDN）システムのコアコンポーネントです。ネットワークトラフィックの最適なパスを計算し、既存のパスを更新して、ネットワークまたはトラフィックの需要の変更を反映するために使用できます。PCEは、MPLSネットワークのトラフィックエンジニアリング（TE）パスを導出するために開発されました。MPLSネットワークは、パス計算要素通信プロトコル（PCEP）を使用してパスのヘッドエンドに供給されます。 +

+
+
+
+
+

+SDN has much broader applicability than signalled MPLS TE networks, and the PCE may be used to determine paths in a range of use cases including static Label-Switched Paths (LSPs), Segment Routing (SR), Service Function Chaining (SFC), and most forms of a routed or switched network. Therefore, it is reasonable to consider PCEP as a control protocol for use in these environments to allow the PCE to be fully enabled as a central controller. +

+
+
+

+SDNは、シグナル付きMPLS TEネットワークよりもはるかに広い適用性があり、PCEを使用して、静的ラベルスイッチングパス（LSP）、セグメントルーティング（SR）、サービス関数チェーン（SFC）、、および範囲のユースケースのパスを決定することができます。ルーティングまたはスイッチネットワークのほとんどの形式。したがって、PCEPをこれらの環境で使用するためのコントロールプロトコルとして考慮して、PCEを中央コントローラーとして完全に有効にすることを可能にすることが合理的です。 +

+
+
+
+
+

+A PCE as a Central Controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN without necessarily completely replacing it. This document describes general considerations for PCECC deployment and examines its applicability and benefits, as well as its challenges and limitations, through a number of use cases. PCEP extensions, which are required for the PCECC use cases, are covered in separate documents. +

+
+
+

+セントラルコントローラー（PCECC）としてのPCEは、必ずしも完全に置き換えることなく、SDNの要素とブレンドすることにより、分散コントロールプレーンの処理を簡素化できます。このドキュメントは、PCECCの展開に関する一般的な考慮事項について説明し、多くのユースケースを通じて、その適用性と利点、およびその課題と制限を調べます。PCECCユースケースに必要なPCEP拡張機能は、個別のドキュメントでカバーされています。 +

+
+
+
+
+
+Status of This Memo +
+
+
+
+本文書の位置付け +
+
+
+
+
+

+This document is not an Internet Standards Track specification; it is published for informational purposes. +

+
+
+

+このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。 +

+
+
+
+
+

+This document is a product of the Internet 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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841. +

+
+
+

+このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。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/rfc9689. +

+
+
+

+このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9689で取得できます。 +

+
+
+
+
+
+Copyright Notice +
+
+
+
+著作権表示 +
+
+
+
+
+

+Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. +

+
+
+

+著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。 +

+
+
+
+
+

+This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. +

+
+
+

+このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。 +

+
+
+
+
+
+Table of Contents +
+
+
+
+目次 +
+
+
+
+
+ 
+   1.  Introduction
+   2.  Terminology
+   3.  Use Cases
+     3.1.  PCECC for Label Management
+     3.2.  PCECC and SR
+       3.2.1.  PCECC SID Allocation for SR-MPLS
+       3.2.2.  PCECC for SR-MPLS Best Effort (BE) Paths
+       3.2.3.  PCECC for SR-MPLS TE Paths
+       3.2.4.  PCECC for SRv6
+     3.3.  PCECC for Static TE LSPs
+     3.4.  PCECC for Load Balancing (LB)
+     3.5.  PCECC and Inter-AS TE
+     3.6.  PCECC for Multicast LSPs
+       3.6.1.  PCECC for the Setup of P2MP/MP2MP LSPs
+       3.6.2.  PCECC for the End-to-End Protection of P2MP/MP2MP LSPs
+       3.6.3.  PCECC for the Local Protection of P2MP/MP2MP LSPs
+     3.7.  PCECC for Traffic Classification
+     3.8.  PCECC for SFC
+     3.9.  PCECC for Native IP
+     3.10. PCECC for BIER
+   4.  IANA Considerations
+   5.  Security Considerations
+   6.  References
+     6.1.  Normative References
+     6.2.  Informative References
+   Appendix A.  Other Use Cases of the PCECC
+     A.1.  PCECC for Network Migration
+     A.2.  PCECC for L3VPN and PWE3
+     A.3.  PCECC for Local Protection (RSVP-TE)
+     A.4.  Using Reliable P2MP TE-Based Multicast Delivery for
+           Distributed Computations (MapReduce-Hadoop)
+   Acknowledgments
+   Contributors
+   Authors' Addresses
+
+
+
+
+
+
+1. Introduction +
+
+
+
+1. はじめに +
+
+
+
+
+

+The PCE [RFC4655] was developed to offload the path computation function from routers in an MPLS Traffic Engineering (TE) network. It can compute optimal paths for traffic across a network and can also update the paths to reflect changes in the network or traffic demands. The role and function of the PCE have grown to cover several other uses (such as GMPLS [RFC7025] or Multicast) and to allow delegated stateful control [RFC8231] and PCE-initiated use of network resources [RFC8281]. +

+
+
+

+PCE [RFC4655]は、MPLSトラフィックエンジニアリング（TE）ネットワークのルーターからパス計算関数をオフロードするために開発されました。ネットワーク間のトラフィックに最適なパスを計算でき、ネットワークまたはトラフィックの要求の変更を反映するパスを更新することもできます。PCEの役割と機能は、他のいくつかの用途（GMPLS [RFC7025]やマルチキャストなど）をカバーし、委任されたステートフルコントロール[RFC8231]およびネットワークリソースの使用[RFC8281]の委任された使用を可能にするように成長しました。 +

+
+
+
+
+

+According to [RFC7399], Software-Defined Networking (SDN) refers to a separation between the control elements and the forwarding components so that software running in a centralized system, called a "controller", can act to program the devices in the network to behave in specific ways. A required element in an SDN architecture is a component that plans how the network resources will be used and how the devices will be programmed. It is possible to view this component as performing specific computations to place traffic flows within the network given knowledge of the availability of the network resources, how other forwarding devices are programmed, and the way that other flows are routed. This is the function and purpose of a PCE, and the way that a PCE integrates into a wider network control system (including an SDN system) is presented in [RFC7491]. +

+
+
+

+[RFC7399]によると、ソフトウェア定義ネットワーク（SDN）とは、「コントローラー」と呼ばれる集中システムで実行されるソフトウェアがネットワーク内のデバイスをプログラムするように動作するように、制御要素と転送コンポーネントの分離を指します。特定の方法で動作します。SDNアーキテクチャに必要な要素は、ネットワークリソースの使用方法とデバイスのプログラム方法を計画するコンポーネントです。このコンポーネントを、ネットワークリソースの可用性、他の転送デバイスのプログラム方法、および他のフローのルーティング方法に関する知識を考慮して、ネットワーク内にトラフィックフローを配置する特定の計算を実行すると見なすことができます。これはPCEの機能と目的であり、PCEがより広いネットワーク制御システム（SDNシステムを含む）に統合する方法が[RFC7491]に表示されます。 +

+
+
+
+
+

+[RFC8283] outlines the architecture for the PCE as a central controller, extending the framework described in [RFC4655], and demonstrates how PCEP can serve as a general southbound control protocol between the PCE and Path Computation Client (PCC). [RFC8283] further examines the motivations and applicability of PCEP as a Southbound Interface (SBI) and introduces the implications for the protocol. +

+
+
+

+[RFC8283]は、[RFC4655]で説明されているフレームワークを拡張し、PCEがPCEとPATH計算クライアント（PCC）の間の一般的な南行きのコントロールプロトコルとして機能する方法を示し、中央コントローラーとしてのPCEのアーキテクチャの概要を示しています。[RFC8283]は、南行きの界面（SBI）としてのPCEPの動機と適用性をさらに調べ、プロトコルへの影響を導入します。 +

+
+
+
+
+

+[RFC9050] introduces the procedures and extensions for PCEP to support the PCECC architecture [RFC8283]. +

+
+
+

+[RFC9050]は、PCEPアーキテクチャをサポートするためにPCEPの手順と拡張機能を導入します[RFC8283]。 +

+
+
+
+
+

+This document describes the various use cases for the PCECC architecture. +

+
+
+

+このドキュメントでは、PCECCアーキテクチャのさまざまなユースケースについて説明しています。 +

+
+
+
+
+
+2. Terminology +
+
+
+
+2. 用語 +
+
+
+
+
+

+The following terminology is used in this document. +

+
+
+

+このドキュメントでは、次の用語が使用されています。 +

+
+
+
+
+

+AS: +

+
+
+

+AS: +

+
+
+
+
+

+Autonomous System +

+
+
+

+自律システム +

+
+
+
+
+

+ASBR: +

+
+
+

+ASBR： +

+
+
+
+
+

+Autonomous System Border Router +

+
+
+

+自律システムボーダールーター +

+
+
+
+
+

+BGP-LS: +

+
+
+

+BGP-LS： +

+
+
+
+
+

+Border Gateway Protocol - Link State [RFC9552] +

+
+
+

+Border Gatewayプロトコル - リンク状態[RFC9552] +

+
+
+
+
+

+IGP: +

+
+
+

+IGP: +

+
+
+
+
+

+Interior Gateway Protocol (in this document, we assume IGP as either Open Shortest Path First (OSPF) [RFC2328] [RFC5340] or Intermediate System to Intermediate System (IS-IS) [RFC1195]) +

+
+
+

+インテリアゲートウェイプロトコル（このドキュメントでは、IGPは最初に最短パスを開く（OSPF）[RFC2328] [RFC5340]または中間システムから中間システム（IS-IS）[RFC1195]のいずれかと仮定します） +

+
+
+
+
+

+LSP: +

+
+
+

+LSP: +

+
+
+
+
+

+Label-Switched Path +

+
+
+

+ラベルスイッチパス +

+
+
+
+
+

+PCC: +

+
+
+

+PCC: +

+
+
+
+
+

+Path Computation Client (as per [RFC4655], any client application requesting a path computation to be performed by a PCE) +

+
+
+

+パス計算クライアント（[RFC4655]によると、PCEによって実行されるパス計算を要求するクライアントアプリケーション） +

+
+
+
+
+

+PCE: +

+
+
+

+PCE: +

+
+
+
+
+

+Path Computation Element (as per [RFC4655], an entity such as a component, application, or network node that is capable of computing a network path or route based on a network graph and applying computational constraints) +

+
+
+

+パス計算要素（[RFC4655]によると、ネットワークグラフに基づいてネットワークパスまたはルートを計算し、計算上の制約を適用できるコンポーネント、アプリケーション、またはネットワークノードなどのエンティティ） +

+
+
+
+
+

+PCECC: +

+
+
+

+PCECC： +

+
+
+
+
+

+PCE as a Central Controller (an extension of a PCE to support SDN functions as per [RFC8283]) +

+
+
+

+中央コントローラーとしてのPCE（[RFC8283]に従ってSDN関数をサポートするPCEの拡張） +

+
+
+
+
+

+PST: +

+
+
+

+PST: +

+
+
+
+
+

+Path Setup Type [RFC8408] +

+
+
+

+パスセットアップタイプ[RFC8408] +

+
+
+
+
+

+RR: +

+
+
+

+RR: +

+
+
+
+
+

+Route Reflector [RFC4456] +

+
+
+

+ルートリフレクター[RFC4456] +

+
+
+
+
+

+SID: +

+
+
+

+SID: +

+
+
+
+
+

+Segment Identifier [RFC8402] +

+
+
+

+セグメント識別子[RFC8402] +

+
+
+
+
+

+SR: +

+
+
+

+SR: +

+
+
+
+
+

+Segment Routing [RFC8402] +

+
+
+

+セグメントルーティング[RFC8402] +

+
+
+
+
+

+SRGB: +

+
+
+

+SRGB： +

+
+
+
+
+

+Segment Routing Global Block [RFC8402] +

+
+
+

+セグメントルーティンググローバルブロック[RFC8402] +

+
+
+
+
+

+SRLB: +

+
+
+

+SRLB： +

+
+
+
+
+

+Segment Routing Local Block [RFC8402] +

+
+
+

+セグメントルーティングローカルブロック[RFC8402] +

+
+
+
+
+

+TE: +

+
+
+

+TE: +

+
+
+
+
+

+Traffic Engineering [RFC9522] +

+
+
+

+交通工学[RFC9522] +

+
+
+
+
+
+3. Use Cases +
+
+
+
+3. ユースケース +
+
+
+
+
+

+[RFC8283] describes various use cases for a PCECC such as: +

+
+
+

+[RFC8283]は、次のようなPCECCのさまざまなユースケースを説明しています。 +

+
+
+
+
+

+* use of a PCECC to set up static TE LSPs (the PCEP extension for this use case is in [RFC9050]) +

+
+
+

+* PCECCを使用して静的TE LSPをセットアップします（このユースケースのPCEP拡張は[RFC9050]にあります） +

+
+
+
+
+

+* use of a PCECC in SR [RFC8402] +

+
+
+

+* SR [RFC8402]でのPCECCの使用 +

+
+
+
+
+

+* use of a PCECC to set up Multicast Point-to-Multipoint (P2MP) LSPs +

+
+
+

+* PCECCを使用してマルチキャストポイントツーマルチポイント（P2MP）LSP +

+
+
+
+
+

+* use of a PCECC to set up Service Function Chaining (SFC) [RFC7665] +

+
+
+

+* PCECCを使用してサービス関数チェーン（SFC）[RFC7665]をセットアップします +

+
+
+
+
+

+* use of a PCECC in optical networks +

+
+
+

+* 光ネットワークでのPCECCの使用 +

+
+
+
+
+

+Section 3.1 describes the general case of a PCECC being in charge of managing MPLS label space, which is a prerequisite for further use cases. Further, various use cases (SR, Multicast, etc.) are described in the following sections to showcase scenarios that can benefit from the use of a PCECC. +

+
+
+

+セクション3.1では、MPLSラベルスペースの管理を担当するPCECCの一般的なケースについて説明します。これは、さらなるユースケースの前提条件です。さらに、PCECCの使用から利益を得ることができるシナリオを紹介するために、以下のセクションでさまざまなユースケース（SR、マルチキャストなど）について説明します。 +

+
+
+
+
+

+It is interesting to note that some of the use cases listed can also be supported via BGP instead of PCEP. However, within the scope of this document, the focus is on the use of PCEP. +

+
+
+

+リストされているユースケースの一部は、PCEPの代わりにBGPを介してサポートできることに注意するのは興味深いことです。ただし、このドキュメントの範囲内では、PCEPの使用に焦点が当てられています。 +

+
+
+
+
+
+3.1. PCECC for Label Management +
+
+
+
+3.1. ラベル管理用のPCECC +
+
+
+
+
+

+As per [RFC8283], in some cases, the PCECC can take responsibility for managing some part of the MPLS label space for each of the routers that it controls, and it may take wider responsibility for partitioning the label space for each router and allocating different parts for different uses, communicating the ranges to the router using PCEP. +

+
+
+

+[RFC8283]によると、場合によっては、PCECCは、制御する各ルーターのMPLSラベルスペースの一部を管理する責任を負う可能性があり、各ルーターのラベルスペースを分割し、異なる異なるものを割り当てる責任を負う可能性があります。さまざまな用途の部品、PCEPを使用してルーターに範囲を伝えます。 +

+
+
+
+
+

+[RFC9050] describes a mode where LSPs are provisioned as explicit label instructions at each hop on the end-to-end path. Each router along the path must be told what label forwarding instructions to program and what resources to reserve. The controller uses PCEP to communicate with each router along the path of the end-to-end LSP. For this to work, the PCECC will take responsibility for managing some part of the MPLS label space for each of the routers that it controls. An extension to PCEP could be done to allow a PCC to inform the PCE of such a label space to control (see [PCE-ID] for a possible PCEP extension to support the advertisement of the MPLS label space for the PCE to control). +

+
+
+

+[RFC9050]は、LSPがエンドツーエンドパスの各ホップで明示的なラベル命令としてプロビジョニングされるモードを記述します。パスに沿った各ルーターは、プログラムするラベル転送指示と予約するリソースを伝える必要があります。コントローラーは、PCEPを使用して、エンドツーエンドLSPのパスに沿って各ルーターと通信します。これが機能するためには、PCECCは、制御する各ルーターのMPLSラベルスペースの一部を管理する責任を負います。PCCPの拡張機能は、PCCがこのようなラベルスペースのPCEに制御するための通知を許可するために実行できます（PCEを制御するためのMPLSラベルスペースの広告をサポートするために、可能なPCEP拡張について[PCE-ID]を参照）。 +

+
+
+
+
+

+[RFC8664] specifies extensions to PCEP that allow a stateful PCE to compute, update, or initiate SR-TE paths. [PCECC-SR] describes the mechanism for a PCECC to allocate and provision the node/prefix/ adjacency label (Segment Routing Identifier (SID)) via PCEP. To make such an allocation, the PCE needs to be aware of the label space from the Segment Routing Global Block (SRGB) or Segment Routing Local Block (SRLB) [RFC8402] of the node that it controls. A mechanism for a PCC to inform the PCE of such a label space to control is needed within the PCEP. The full SRGB/SRLB of a node could be learned via existing IGP or BGP-LS [RFC9552] mechanisms. +

+
+
+

+[RFC8664]は、ステートフルPCEがSR-TEパスを計算、更新、または開始できるようにするPCEPへの拡張機能を指定します。[PCECC-SR]は、PCECCがPCEPを介してノード/プレフィックス/隣接ラベル（セグメントルーティング識別子（SID））を割り当ててプロビジョニングするメカニズムを説明しています。このような割り当てを行うには、PCEが、それが制御するノードのローカルブロック（SRLB）[RFC8402]をルーティングするセグメントルーティンググローバルブロック（SRGB）またはセグメントルーティングのラベルスペースを認識する必要があります。PCCがPCEを制御するためにPCEに通知するメカニズムがPCEP内で必要です。ノードの完全なSRGB/SRLBは、既存のIGPまたはBGP-LS [RFC9552]メカニズムを介して学習できます。 +

+
+
+
+
+

+Further, there have been proposals for a global label range in MPLS as well as the use of PCECC architecture to learn the label space of each node to determine and provision the global label range. +

+
+
+

+さらに、MPLSのグローバルラベル範囲と、各ノードのラベルスペースを学習してグローバルラベル範囲を決定および提供するためのPCECCアーキテクチャの使用についての提案がありました。 +

+
+
+
+
+ 
+   +------------------------------+    +------------------------------+
+   |         PCE DOMAIN 1         |    |         PCE DOMAIN 2         |
+   |          +--------+          |    |          +--------+          |
+   |          |        |          |    |          |        |          |
+   |          | PCECC1 |  ---------PCEP---------- | PCECC2 |          |
+   |          |        |          |    |          |        |          |
+   |          |        |          |    |          |        |          |
+   |          +--------+          |    |          +--------+          |
+   |         ^          ^         |    |         ^          ^         |
+   |        /            \  PCEP  |    |  PCEP  /            \        |
+   |       V              V       |    |       V              V       |
+   | +--------+        +--------+ |    | +--------+        +--------+ |
+   | | Node11 |        | Node1n | |    | | Node21 |        | Node2n | |
+   | |        | ...... |        | |    | |        | ...... |        | |
+   | | PCECC  |        |  PCECC | |    | | PCECC  |        |PCECC   | |
+   | |Enabled |        | Enabled| |    | |Enabled |        |Enabled | |
+   | +--------+        +--------+ |    | +--------+        +--------+ |
+   |                              |    |                              |
+   +------------------------------+    +------------------------------+
+
+
+
+
+
+

+Figure 1: PCECC for MPLS Label Management +

+
+
+

+図1：MPLSラベル管理用PCECC +

+
+
+
+
+

+As shown in Figure 1: +

+
+
+

+図1に示すように： +

+
+
+
+
+

+* The PCC will advertise the PCECC capability to the PCECC [RFC9050]. +

+
+
+

+* PCCは、PCECC機能をPCECC [RFC9050]に宣伝します。 +

+
+
+
+
+

+* The PCECC could also learn the label range set aside by the PCC (via [PCE-ID]). +

+
+
+

+* PCECCは、PCC（[PCE-ID]を介して）によって確保されたラベル範囲を学習することもできます。 +

+
+
+
+
+

+* Optionally, the PCECC could determine the shared MPLS global label range for the network. +

+
+
+

+* オプションで、PCECCはネットワークの共有MPLSグローバルラベル範囲を決定できます。 +

+
+
+
+
+

+- In the case that the shared global label range needs to be negotiated across multiple domains, the central controllers of these domains will also need to negotiate a common global label range across domains. +

+
+
+

+- 共有されたグローバルラベル範囲を複数のドメインでネゴシエートする必要がある場合、これらのドメインの中央コントローラーは、ドメイン全体で共通のグローバルラベル範囲をネゴシエートする必要があります。 +

+
+
+
+
+

+- The PCECC will need to set the shared global label range to all PCC nodes in the network. +

+
+
+

+- PCECCは、ネットワーク内のすべてのPCCノードに共有グローバルラベル範囲を設定する必要があります。 +

+
+
+
+
+

+As per [RFC9050], the PCECC could also rely on the PCC to make label allocations initially and use PCEP to distribute it to where it is needed. +

+
+
+

+[RFC9050]によると、PCECCはPCCに依存してラベル割り当てを最初に行い、PCEPを使用して必要な場所に配布することもできます。 +

+
+
+
+
+
+3.2. PCECC and SR +
+
+
+
+3.2. PCECCおよびSR +
+
+
+
+
+

+SR [RFC8402] leverages the source routing paradigm. Using SR, a source node steers a packet through a path without relying on hop-by-hop signalling protocols such as LDP [RFC5036] or RSVP-TE [RFC3209]. Each path is specified as an ordered list of instructions called "segments". Each segment is an instruction to route the packet to a specific place in the network or to perform a specific service on the packet. A database of segments can be distributed through the network using an intra-domain routing protocol (such as IS-IS or OSPF), an inter-domain protocol (such as BGP), or by any other means. PCEP could also be one of other protocols. +

+
+
+

+SR [RFC8402]は、ソースルーティングパラダイムを活用します。SRを使用して、ソースノードは、LDP [RFC5036]やRSVP-TE [RFC3209]などのホップバイホップシグナリングプロトコルに依存せずにパスをパケットに導きます。各パスは、「セグメント」と呼ばれる命令の順序付けリストとして指定されています。各セグメントは、パケットをネットワーク内の特定の場所にルーティングしたり、パケットで特定のサービスを実行する命令です。セグメントのデータベースは、ドメイン内ルーティングプロトコル（IS-ISやOSPFなど）、ドメイン間プロトコル（BGPなど）、またはその他の手段でネットワークを介して配布できます。PCEPは、他のプロトコルの1つでもあります。 +

+
+
+
+
+

+[RFC8664] specifies the PCEP extension specific to SR for SR over MPLS (SR-MPLS). The PCECC may further use the PCEP for distributing SR Segment Identifiers (SIDs) to the SR nodes (PCC) with some benefits. If the PCECC allocates and maintains the SIDs in the network for the nodes and adjacencies, and further distributes them to the SR nodes directly via the PCEP session, then it is more advantageous over the configurations on each SR node and flooding them via IGP, especially in an SDN environment. +

+
+
+

+[RFC8664]は、MPLS（SR-MPLS）のSRのSRに固有のPCEP拡張を指定します。PCECCはさらに、SRセグメント識別子（SIDS）をSRノード（PCC）に分配するためにPCEPを使用して、いくつかの利点があります。PCECCがノードと隣接のネットワーク内のSIDを割り当てて維持し、PCEPセッションを介してSRノードにさらに配布する場合、各SRノードの構成よりも有利であり、特にIGPを介してそれらをあふれさせることはより有利です。SDN環境で。 +

+
+
+
+
+

+When the PCECC is used for the distribution of the Node-SID and Adj-SID for SR-MPLS, the Node-SID is allocated from the SRGB of the node and the Adj-SID is allocated from the SRLB of the node as described in [PCECC-SR]. +

+
+
+

+PCECCがSR-MPLS用のノードSIDおよびadj-SIDの分布に使用される場合、ノードSIDはノードのSRGBから割り当てられ、adj-SIDはノードのSRLBから割り当てられます。[PCECC-SR]。 +

+
+
+
+
+

+[RFC8355] identifies various protection and resiliency use cases for SR. Path protection lets the ingress node be in charge of the failure recovery (used for SR-TE [RFC8664]). Also, protection can be performed by the node adjacent to the failed component, commonly referred to as "local protection techniques" or "fast-reroute (FRR) techniques". In the case of the PCECC, the protection paths can be precomputed and set up by the PCE. +

+
+
+

+[RFC8355]は、SRのさまざまな保護および回復力のユースケースを特定します。パス保護により、イングレスノードが障害回復を担当することができます（SR-TE [RFC8664]に使用）。また、保護は、一般に「ローカル保護技術」または「Fast-Reroute（FRR）技術」と呼ばれる故障コンポーネントに隣接するノードによって実行できます。PCECCの場合、PCEによって保護パスを事前計算して設定できます。 +

+
+
+
+
+

+Figure 2 illustrates the use case where the Node-SID and Adj-SID are allocated by the PCECC for SR-MPLS. +

+
+
+

+図2は、SR-MPLSのためにPCECCによってノードSIDおよびadj-SIDが割り当てられるユースケースを示しています。 +

+
+
+
+
+ 
+                          192.0.2.1/32
+                          +----------+
+                          | R1(1001) |
+                          +----------+
+                               |
+                          +----------+
+                          | R2(1002) |  192.0.2.2/32
+                          +----------+
+                         *   |   *    *
+                        *    |   *     *
+                       *link1|   *      *
+        192.0.2.4/32  *      |   *link2  *  192.0.2.5/32
+           +-----------+ 9001|   *     +-----------+
+           | R4(1004)  |     |   *     | R5(1005)  |
+           +-----------+     |   *     +-----------+
+                      *      |   *9003  *   +
+                       *     |   *     *    +
+                        *    |   *    *     +
+                        +-----------+   +-----------+
+           192.0.2.3/32 | R3(1003)  |   |R6(1006)   |192.0.2.6/32
+                        +-----------+   +-----------+
+                             |
+                        +-----------+
+                        | R8(1008)  |  192.0.2.8/32
+                        +-----------+
+
+
+
+
+
+

+Figure 2: SR Topology +

+
+
+

+図2：SRトポロジー +

+
+
+
+
+
+3.2.1. PCECC SID Allocation for SR-MPLS +
+
+
+
+3.2.1. SR-MPLSのPCECC SID割り当て +
+
+
+
+
+

+Each node (PCC) is allocated a Node-SID by the PCECC. The PCECC needs to update the label mapping of each node to all the other nodes in the domain. After receiving the label mapping, each node (PCC) uses the local routing information to determine the next hop and download the label forwarding instructions accordingly. The forwarding behavior and the end result are the same as IGP shortest-path SR forwarding based on Node-SIDs. Thus, from anywhere in the domain, it enforces the ECMP-aware shortest-path forwarding of the packet towards the related node. +

+
+
+

+各ノード（PCC）は、PCECCによってノードSIDを割り当てられます。PCECCは、各ノードのラベルマッピングをドメイン内の他のすべてのノードに更新する必要があります。ラベルマッピングを受信した後、各ノード（PCC）はローカルルーティング情報を使用して次のホップを決定し、それに応じてラベル転送手順をダウンロードします。転送の動作と最終結果は、ノードSIDに基づくIGP最短パスSR転送と同じです。したがって、ドメインのどこからでも、関連するノードに向けてパケットのECMPを認識している最短パス転送を実施します。 +

+
+
+
+
+

+The PCECC can allocate an Adj-SID for each adjacency in the network. The PCECC sends a PCInitiate message to update the label mapping of each adjacency to the corresponding nodes in the domain. Each node (PCC) downloads the label forwarding instructions accordingly. The forwarding behavior and the end result are similar to IGP-based Adj-SID allocation and usage in SR. +

+
+
+

+PCECCは、ネットワーク内の各隣接にadj-SIDを割り当てることができます。PCECCはPCINITIATEメッセージを送信して、各隣接のラベルマッピングをドメイン内の対応するノードに更新します。各ノード（PCC）は、それに応じてラベル転送手順をダウンロードします。転送挙動と最終結果は、SRのIGPベースのADJ-SID割り当てと使用に似ています。 +

+
+
+
+
+

+These mechanisms are described in [PCECC-SR]. +

+
+
+

+これらのメカニズムは[PCECC-SR]で説明されています。 +

+
+
+
+
+
+3.2.2. PCECC for SR-MPLS Best Effort (BE) Paths +
+
+
+
+3.2.2. SR-MPLSのPCECC最善の努力（BE）パス +
+
+
+
+
+

+When using PCECC for SR-MPLS Best Effort (BE) Paths, the PCECC needs to allocate the Node-SID (without calculating the explicit path for the SR path). The ingress router of the forwarding path needs to encapsulate the destination Node-SID on top of the packet. All the intermediate nodes will forward the packet based on the destination Node-SID. It is similar to the LDP LSP. +

+
+
+

+SR-MPLSの最善の努力（BE）パスにPCECCを使用する場合、PCECCはノードSIDを割り当てる必要があります（SRパスの明示的なパスを計算せずに）。転送パスのイングレスルーターは、パケットの上に宛先ノードSIDをカプセル化する必要があります。すべての中間ノードは、宛先ノードSIDに基づいてパケットを転送します。LDP LSPに似ています。 +

+
+
+
+
+

+R1 may send a packet to R8 simply by pushing an SR label with segment {1008} (Node-SID for R8). The path will be based on the routing / next hop calculation on the routers. +

+
+
+

+R1は、SRラベルをセグメント{1008}（R8用のノードSID）でプッシュするだけで、R8にパケットを送信できます。パスは、ルーターのルーティング /次のホップ計算に基づいています。 +

+
+
+
+
+
+3.2.3. PCECC for SR-MPLS TE Paths +
+
+
+
+3.2.3. SR-MPLS TEパス用のPCECC +
+
+
+
+
+

+SR-TE paths may not follow an IGP shortest path tree (SPT). Such paths may be chosen by a PCECC and provisioned on the ingress node of the SR-TE path. The SR header consists of a list of SIDs (or MPLS labels). The header has all necessary information so that the packets can be guided from the ingress node to the egress node of the path. Hence, there is no need for any signalling protocol. For the case where a strict traffic engineering path is needed, all the Adj-SIDs are stacked; otherwise, a combination of Node-SIDs or Adj-SIDs can be used for the SR-TE paths. +

+
+
+

+SR-TEパスは、IGP最短パスツリー（SPT）をたどることはできません。このようなパスは、PCECCによって選択され、SR-TEパスのイングレスノードにプロビジョニングされる場合があります。SRヘッダーは、SIDS（またはMPLSラベル）のリストで構成されています。ヘッダーにはすべての必要な情報があるため、パケットをイングレスノードからパスの出力ノードに誘導できます。したがって、シグナル伝達プロトコルは必要ありません。厳格な交通工学パスが必要な場合、すべてのadj-SIDが積み重ねられます。それ以外の場合、SR-TEパスにノードSIDまたはADJ-SIDの組み合わせを使用できます。 +

+
+
+
+
+

+As shown in Figure 3, R1 may send a packet to R8 by pushing an SR header with segment list {1002, 9001, 1008}, where 1002 and 1008 are the Node-SIDs of R2 and R8, respectively. 9001 is the Adj-SID for link1. The path should be: "R1-R2-link1-R3-R8". +

+
+
+

+図3に示すように、R1は、セグメントリスト{1002、9001、1008}でSRヘッダーをプッシュすることによりR8にパケットを送信する場合があります。1002と1008はそれぞれR2とR8のノードシドです。9001は、link1のadj-sidです。パスは次のとおりです。「R1-R2-Link1-R3-R8」。 +

+
+
+
+
+

+To achieve this, the PCECC first allocates and distributes SIDs as described in Section 3.2.1. [RFC8664] describes the mechanism for a PCE to compute, update, or initiate SR-MPLS TE paths. +

+
+
+

+これを達成するために、PCECCは、セクション3.2.1で説明されているように、最初にSIDを割り当てて配布します。[RFC8664]は、PCEがSR-MPLS TEパスを計算、更新、または開始するメカニズムを説明しています。 +

+
+
+
+
+ 
+                         192.0.2.1/32
+                         +----------+
+                         | R1 (1001)|
+                         +----------+
+                           |       |
+                    90011  |       |90012
+                    link1  |       |link2
+                          +----------+
+                          | R2 (1002)|  192.0.2.2/32
+                          +----------+
+                   link3 *   |   *    * link4
+                  90023 *    |   *     * 90024
+                       *link5|   *      *
+        192.0.2.4/32  *90025 |   *link6  *  192.0.2.5/32
+           +-----------+     |   *90026+-----------+
+           | R4 (1004) |     |   *     | R5 (1005) |
+           +-----------+     |   *     +-----------+
+                      *      |   *             +
+               link10  *     |   *     link7   +
+                        *    |   *             +
+                        +-----------+   +-----------+
+           192.0.2.3/32 | R3 (1003) |   |R6 (1006)  |192.0.2.6/32
+                        +-----------+   +-----------+
+                         |                   |
+                         |link8              |
+                         |        |----------|link9
+                        +-----------+
+                        | R8 (1008) |  192.0.2.8/32
+                        +-----------+
+
+
+
+
+
+

+Figure 3: PCECC TE LSP Setup Example +

+
+
+

+図3：PCECC TE LSPセットアップの例 +

+
+
+
+
+

+Refer to Figure 3 for an example of TE topology, where 100x are Node-SIDs and 900xx are Adj-SIDs. +

+
+
+

+TEトポロジの例については、図3を参照してください。100xはノードシドで、900xxはadj-sidsです。 +

+
+
+
+
+

+* The SID allocation and distribution are done by the PCECC with all Node-SIDs (100x) and all Adj-SIDs (900xx). +

+
+
+

+* SIDの割り当てと分布は、すべてのノードSID（100x）およびすべてのadj-SID（900xx）を備えたPCECCによって行われます。 +

+
+
+
+
+

+* Based on path computation request/delegation or PCE initiation, the PCECC receives a request with constraints and optimization criteria from a PCC. +

+
+
+

+* PATH計算要求/委任またはPCEの開始に基づいて、PCECCはPCCから制約と最適化基準を備えた要求を受け取ります。 +

+
+
+
+
+

+* The PCECC will calculate the optimal path according to the given constraints (e.g., bandwidth (BW)). +

+
+
+

+* PCECCは、指定された制約（例：帯域幅（BW））に従って最適なパスを計算します。 +

+
+
+
+
+

+* The PCECC will provision the SR-MPLS TE LSP path ("R1-link1-R2-link6-R3-R8") at the ingress node: {90011, 1002, 90026, 1003, 1008} +

+
+
+

+* PCECCは、SR-MPLS TE LSPパス（ "R1-Link1-R2-Link6-R3-R8"）をIngressノードにプロビジョニングします：{90011、1002、90026、1003、1008} +

+
+
+
+
+

+* For the end-to-end protection, the PCECC can provision the secondary path ("R1-link2-R2-link4-R5-R8"): {90012, 1002, 90024, 1005, 1008}. +

+
+
+

+* エンドツーエンドの保護のために、PCECCはセカンダリパス（ "R1-Link2-R2-Link4-R5-R8"）をプロビジョニングできます：{90012、1002、90024、1005、1008}。 +

+
+
+
+
+
+3.2.3.1. PCECC for SR Policy +
+
+
+
+3.2.3.1. SRポリシーのPCECC +
+
+
+
+
+

+[RFC8402] defines SR architecture, which uses an SR Policy to steer packets from a node through an ordered list of segments. The SR Policy could be configured on the headend or instantiated by an SR controller. The SR architecture does not restrict how the controller programs the network. In this case, the focus is on PCEP as the protocol for SR Policy delivery from the PCE to PCC. +

+
+
+

+[RFC8402]は、SRアーキテクチャを定義します。SRアーキテクチャは、SRポリシーを使用して、順序付けられたセグメントリストを介してノードからパケットを操縦します。SRポリシーは、ヘッドエンドで構成するか、SRコントローラーによってインスタンス化される可能性があります。SRアーキテクチャは、コントローラーがネットワークをどのようにプログラムするかを制限していません。この場合、PCCからPCCへのSRポリシー提供のプロトコルとしてのPCEPに焦点が当てられています。 +

+
+
+
+
+

+An SR Policy architecture is described in [RFC9256]. An SR Policy is a framework that enables the instantiation of an ordered list of segments on a node for implementing a source routing policy for the steering of traffic for a specific purpose (e.g., for a specific Service Level Agreement (SLA)) from that node. +

+
+
+

+SRポリシーアーキテクチャは[RFC9256]で説明されています。SRポリシーは、特定の目的のためのトラフィックのステアリング（例：特定のサービスレベル契約（SLA）など）のソースルーティングポリシーを実装するためのノード上の順序付けられたセグメントリストのインスタンス化を可能にするフレームワークです。。 +

+
+
+
+
+

+An SR Policy is identified through the tuple <headend, color, endpoint>. +

+
+
+

+SRポリシーは、tuple <headend、color、endpoint>を通じて識別されます。 +

+
+
+
+
+

+Figure 3 is used as an example of PCECC application for SR Policy instantiation for SR-MPLS, where the Node-SIDs are 100x and the Adj-SIDs are 900xx. +

+
+
+

+図3は、SR-MPLSのSRポリシーインスタンス化のためのPCECCアプリケーションの例として使用されます。ここで、ノードSIDは100倍で、Adj-SIDは900XXです。 +

+
+
+
+
+

+Let's assume that R1 needs to have two disjoint SR Policies towards R8 based on different BWs. This means the possible paths are: +

+
+
+

+R1は、異なるBWSに基づいてR8に対して2つのばらばらのSRポリシーを持つ必要があると仮定しましょう。これは、可能なパスが次のことを意味します。 +

+
+
+
+
+

+* POL1: {Headend R1, color 100, Endpoint R8; Candidate Path1: Segment List 1: {90011, 1002, 90023, 1004, 1003, 1008}} +

+
+
+

+* pol1：{headend R1、Color 100、Endpoint R8;候補PATH1：セグメントリスト1：{90011、1002、90023、1004、1003、1008}} +

+
+
+
+
+

+* POL2: {Headend R1, color 200, Endpoint R8; Candidate Path1: Segment List 1: {90012, 1002, 90024, 1005, 1006, 1008}} +

+
+
+

+* POL2：{HeadEnd R1、Color 200、Endpoint R8;候補PATH1：セグメントリスト1：{90012、1002、90024、1005、1006、1008}}} +

+
+
+
+
+

+Each SR Policy (including the candidate path and segment list) will be signalled to a headend (R1) via PCEP [PCEP-POLICY] with the addition of an ASSOCIATION object. A Binding SID (BSID) [RFC8402] can be used for traffic steering of labelled traffic into an SR Policy; a BSID can be provisioned from the PCECC also via PCEP [RFC9604]. For non-labelled traffic steering into the SR Policy POL1 or POL2, a per-destination traffic steering will be used by means of the BGP Color Extended Community [RFC9012]. +

+
+
+

+各SRポリシー（候補パスとセグメントリストを含む）は、Associationオブジェクトを追加して、PCEP [PCEP-Policy]を介してヘッドエンド（R1）に通知されます。バインディングSID（BSID）[RFC8402]は、SRポリシーへのラベル付きトラフィックのトラフィックステアリングに使用できます。BSIDは、PCEP [RFC9604]を介してPCECCからプロビジョニングできます。SRポリシーPOL1またはPOL2への非標識トラフィックステアリングの場合、BGPカラーの拡張コミュニティ[RFC9012]によって、設定ごとのトラフィックステアリングが使用されます。 +

+
+
+
+
+

+The procedure is as follows: +

+
+
+

+手順は次のとおりです。 +

+
+
+
+
+

+* The PCECC allocates Node-SIDs and Adj-SIDs using the mechanism described in Section 3.2.1 for all nodes and links. +

+
+
+

+* PCECCは、すべてのノードとリンクについてセクション3.2.1で説明したメカニズムを使用して、ノードSIDとadj-SIDを割り当てます。 +

+
+
+
+
+

+* The PCECC calculates disjoint paths for POL1 and POL2 and create segment lists for them: {90011, 1002, 90023, 1004, 1003, 1008};{90012, 1002, 90024, 1005, 1006, 1008}. +

+
+
+

+* PCECCは、POL1およびPOL2の分離パスを計算し、それらのセグメントリストを作成します：{90011、1002、90023、1004、1003、1008}; {90012、1002、90024、1005、1006、1008}。 +

+
+
+
+
+

+* The PCECC forms both SR Policies POL1 and POL2. +

+
+
+

+* PCECCは、SRポリシーPOL1とPOL2の両方を形成します。 +

+
+
+
+
+

+* The PCECC sends both POL1 and POL2 to R1 via PCEP. +

+
+
+

+* PCECCは、PCEPを介してPOL1とPOL2の両方をR1に送信します。 +

+
+
+
+
+

+* The PCECC optionally allocates BSIDs for the SR Policies. +

+
+
+

+* PCECCはオプションで、SRポリシーにBSIDを割り当てます。 +

+
+
+
+
+

+* The traffic from R1 to R8, which fits to color 100, will be steered to POL1 and follows the path: "R1-link1-R2-link3-R4-R3-R8". The traffic from R1 to R8, which fits color 200, will be steered to POL2 and follows the path: "R1-link2-R2-link4-R5-R6-R8". Due to the possibility of having many segment lists in the same candidate path of each POL1/POL2, the PCECC could provision more paths towards R8 and traffic will be balanced either as ECMP or as weighted-ECMP (W-ECMP). This is the advantage of SR Policy architecture. +

+
+
+

+* R1からR8へのトラフィックは、100色に収まり、POL1に操縦され、パス「R1-Link1-R2-Link3-R4-R3-R8」に従います。Color 200に適合するR1からR8へのトラフィックはPOL2に操縦され、パス「R1-Link2-R2-Link4-R5-R6-R8」に従います。各POL1/POL2の同じ候補パスに多くのセグメントリストを持つ可能性があるため、PCECCはR8へのより多くのパスを提供することができ、トラフィックはECMPまたは加重ECMP（W-ECMP）としてバランスが取れます。これがSRポリシーアーキテクチャの利点です。 +

+
+
+
+
+

+Note that an SR Policy can be associated with multiple candidate paths. A candidate path is selected when it is valid and it is determined to be the best path of the SR Policy as described in [RFC9256]. +

+
+
+

+SRポリシーは、複数の候補パスに関連付けられる可能性があることに注意してください。[RFC9256]で説明されているように、候補パスが有効である場合に選択され、SRポリシーの最良のパスであると判断されます。 +

+
+
+
+
+
+3.2.4. PCECC for SRv6 +
+
+
+
+3.2.4. SRV6用PCECC +
+
+
+
+
+

+As per [RFC8402], with SR, a node steers a packet through an ordered list of instructions, called segments. SR can be applied to the IPv6 architecture with the Segment Routing Header (SRH) [RFC8754]. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the destination address of the packet. Upon completion of a segment, a pointer in the new routing header is incremented and indicates the next segment. +

+
+
+

+[RFC8402]によると、SRを使用して、ノードは、セグメントと呼ばれる順序付けられた命令リストを介してパケットを操縦します。SRは、セグメントルーティングヘッダー（SRH）[RFC8754]を使用してIPv6アーキテクチャに適用できます。セグメントはIPv6アドレスとしてエンコードされます。セグメントの順序付けられたリストは、ルーティングヘッダーのIPv6アドレスの順序付けリストとしてエンコードされています。アクティブセグメントは、パケットの宛先アドレスで示されています。セグメントが完了すると、新しいルーティングヘッダーのポインターが増加し、次のセグメントを示します。 +

+
+
+
+
+

+As per [RFC8754], an SR over IPv6 (SRv6) Segment is a 128-bit value. "SRv6 SID" or simply "SID" are often used as a shorter reference for "SRv6 Segment". [RFC8986] defines the SRv6 SID as consisting of LOC:FUNCT:ARG. +

+
+
+

+[RFC8754]によると、IPv6（SRV6）セグメント上のSRは128ビット値です。「SRV6 SID」または単に「SID」は、「SRV6セグメント」のより短い参照としてよく使用されます。[RFC8986]は、SRV6 SIDをloc：funct：argで構成されるものとして定義します。 +

+
+
+
+
+

+[RFC9603] extends [RFC8664] to support SR for the IPv6 data plane. Further, a PCECC could be extended to support SRv6 SID allocation and distribution. An example of how PCEP extensions could be extended for SRv6 for a PCECC is described in [PCECC-SRv6]. +

+
+
+

+[RFC9603]は[RFC8664]を拡張して、IPv6データプレーンのSRをサポートします。さらに、SRV6 SIDの割り当てと分布をサポートするためにPCECCを拡張できます。PCECCのSRV6のPCEP拡張機能をどのように拡張できるかの例は、[PCECC-SRV6]で説明されています。 +

+
+
+
+
+ 
+                          2001:db8::1
+                          +----------+
+                          | R1       |
+                          +----------+
+                               |
+                          +----------+
+                          | R2       |  2001:db8::2
+                          +----------+
+                         *   |   *    *
+                        *    |   *     *
+                       *link1|   *      *
+        2001:db8::4   *      |   *link2  *  2001:db8::5
+           +-----------+     |   *     +-----------+
+           | R4        |     |   *     | R5        |
+           +-----------+     |   *     +-----------+
+                      *      |   *      *   +
+                       *     |   *     *    +
+                        *    |   *    *     +
+                        +-----------+   +-----------+
+           2001:db8::3  | R3        |   |R6         |2001:db8::6
+                        +-----------+   +-----------+
+                             |
+                        +-----------+
+                        | R8        |  2001:db8::8
+                        +-----------+
+
+
+
+
+
+

+Figure 4: PCECC for SRv6 +

+
+
+

+図4：SRV6のPCECC +

+
+
+
+
+

+In this case, as shown in Figure 4, the PCECC could assign the SRv6 SID (in the form of an IPv6 address) to be used for node and adjacency. Later, the SRv6 path in the form of a list of SRv6 SIDs could be used at the ingress. Some examples: +

+
+
+

+この場合、図4に示すように、PCECCはSRV6 SID（IPv6アドレスの形で）を割り当てて、ノードと隣接に使用できます。その後、SRV6 SIDのリストの形のSRV6パスをイングレスで使用できます。いくつかの例： +

+
+
+
+
+

+* The best path towards R8: SRv6 SID-List={2001:db8::8} +

+
+
+

+* R8への最適なパス：SRV6 SID-LIST = {2001：DB8 :: 8} +

+
+
+
+
+

+* The path towards R8 via R5: SRv6 SID-List={2001:db8::5, 2001:db8::8} +

+
+
+

+* R5を介したR8へのパス：SRV6 SID-LIST = {2001：DB8 :: 5、2001：DB8 :: 8} +

+
+
+
+
+

+The rest of the procedures and mechanisms remain the same as SR-MPLS. +

+
+
+

+残りの手順とメカニズムは、SR-MPLと同じままです。 +

+
+
+
+
+
+3.3. PCECC for Static TE LSPs +
+
+
+
+3.3. 静的te LSPのPCECC +
+
+
+
+
+

+As described in Section 3.1.2 of [RFC8283], the PCECC architecture supports the provisioning of static TE LSPs. To achieve this, the existing PCEP can be used to communicate between the PCECC and nodes along the path to provision explicit label instructions at each hop on the end-to-end path. Each router along the path must be told what label-forwarding instructions to program and what resources to reserve. The PCECC keeps a view of the network and determines the paths of the end-to-end LSPs, and the controller uses PCEP to communicate with each router along the path of the end-to-end LSP. +

+
+
+

+[RFC8283]のセクション3.1.2で説明されているように、PCECCアーキテクチャは静的TE LSPのプロビジョニングをサポートしています。これを達成するために、既存のPCEPを使用して、パスに沿ってPCECCとノード間を通信して、エンドツーエンドパスの各ホップで明示的なラベル命令を提供します。パスに沿った各ルーターは、プログラムするためのラベルフォード指示と予約するリソースを伝える必要があります。PCECCはネットワークのビューを保持し、エンドツーエンドLSPのパスを決定し、コントローラーはPCEPを使用して、エンドツーエンドLSPのパスに沿って各ルーターと通信します。 +

+
+
+
+
+ 
+                          192.0.2.1/32
+                         +----------+
+                         | R1       |
+                         +----------+
+                           |       |
+                           |link1  |
+                           |       |link2
+                          +----------+
+                          | R2       |  192.0.2.2/32
+                          +----------+
+                   link3 *   |   *    * link4
+                        *    |   *     *
+                       *link5|   *      *
+        192.0.2.4/32  *      |   *link6  *  192.0.2.5/32
+           +-----------+     |   *     +-----------+
+           | R4        |     |   *     | R5        |
+           +-----------+     |   *     +-----------+
+                      *      |   *      *       +
+               link10  *     |   *     *link7   +
+                        *    |   *    *         +
+                        +-----------+   +-----------+
+           192.0.2.3/32 | R3        |   |R6         |192.0.2.6/32
+                        +-----------+   +-----------+
+                         |         |
+                         |link8    |
+                         |         |link9
+                        +-----------+
+                        | R8        |  192.0.2.8/32
+                        +-----------+
+
+
+
+
+
+

+Figure 5: PCECC TE LSP Setup Example +

+
+
+

+図5：PCECC TE LSPセットアップの例 +

+
+
+
+
+

+Refer to Figure 5 for an example TE topology. +

+
+
+

+TEトポロジの例については、図5を参照してください。 +

+
+
+
+
+

+* Based on path computation request/delegation or PCE initiation, the PCECC receives a request with constraints and optimization criteria. +

+
+
+

+* PATH計算要求/委任またはPCEの開始に基づいて、PCECCは制約と最適化基準を備えた要求を受け取ります。 +

+
+
+
+
+

+* The PCECC will calculate the optimal path according to the given constraints (e.g., BW). +

+
+
+

+* PCECCは、指定された制約（例：BW）に従って最適なパスを計算します。 +

+
+
+
+
+

+* The PCECC will provision each node along the path and assign incoming and outgoing labels from R1 to R8 with the path as "R1-link1-R2-link3-R4-link10-R3-link8-R8": +

+
+
+

+* PCECCは、パスに沿って各ノードをプロビジョニングし、パスを「R1-LINK1-R2-LINK3-RINK10-RINK8-R8」とともにR1からR8に割り当てます： +

+
+
+
+
+

+- R1: Outgoing label 1001 on link 1 +

+
+
+

+- R1：リンク1の発信ラベル1001 +

+
+
+
+
+

+- R2: Incoming label 1001 on link 1 +

+
+
+

+- R2：リンク1の着信ラベル1001 +

+
+
+
+
+

+- R2: Outgoing label 2003 on link 3 +

+
+
+

+- R2：リンク3の発信ラベル2003 +

+
+
+
+
+

+- R4: Incoming label 2003 on link 3 +

+
+
+

+- R4：リンク3の着信ラベル2003 +

+
+
+
+
+

+- R4: Outgoing label 4010 on link 10 +

+
+
+

+- R4：リンク10の発信ラベル4010 +

+
+
+
+
+

+- R3: Incoming label 4010 on link 10 +

+
+
+

+- R3：リンク10の着信ラベル4010 +

+
+
+
+
+

+- R3: Outgoing label 3008 on link 8 +

+
+
+

+- R3：リンク8の発信ラベル3008 +

+
+
+
+
+

+- R8: Incoming label 3008 on link 8 +

+
+
+

+- R8：リンク8の着信ラベル3008 +

+
+
+
+
+

+* This can also be represented as: {R1, link1, 1001}, {1001, R2, link3, 2003}, {2003, R4, link10, 4010}, {4010, R3, link8, 3008}, {3008, R8}. +

+
+
+

+* これは、{r1、link1、1001}、{1001、r2、link3、2003}、{2003、r4、link10、4010}、{4010、r3、link8、3008}、{3008、r8}として次のように表現できます。。 +

+
+
+
+
+

+* For the end-to-end protection, the PCECC programs each node along the path from R1 to R8 with the secondary path: {R1, link2, 1002}, {1002, R2, link4, 2004}, {2004, R5, link7, 5007}, {5007, R3, link9, 3009}, {3009, R8}. +

+
+
+

+* エンドツーエンドの保護のために、PCECCは各ノードをR1からR8へのパスに沿ったセカンダリパスでプログラムします：{r1、link2、1002}、{1002、r2、link4、2004}、{2004、r5、link7、5007}、{5007、r3、link9、3009}、{3009、r8}。 +

+
+
+
+
+

+* It is also possible to have a bypass path for the local protection set up by the PCECC. For example, use the primary path as above, then to protect the node R4 locally, the PCECC can program the bypass path like this: {R2, link5, 2005}, {2005, R3}. By doing this, the node R4 is locally protected at R2. +

+
+
+

+* PCECCによって設定されたローカル保護のバイパスパスを持つこともできます。たとえば、上記のプライマリパスを使用してから、ノードR4をローカルで保護するために、PCECCは次のようなバイパスパスをプログラムできます：{r2、link5、2005}、{2005、r3}。これを行うことにより、ノードR4はR2でローカルで保護されています。 +

+
+
+
+
+
+3.4. PCECC for Load Balancing (LB) +
+
+
+
+3.4. ロードバランシング用PCECC（LB） +
+
+
+
+
+

+Very often, many service providers use TE tunnels for solving issues with non-deterministic paths in their networks. One example of such applications is the usage of TEs in the mobile backhaul (MBH). Consider the topology as shown in Figure 6 (where AGG 1...AGG N are Aggregation routers, and Core 1...Core N are Core routers). +

+
+
+

+多くの場合、多くのサービスプロバイダーは、ネットワーク内の非決定的なパスの問題を解決するためにTEトンネルを使用しています。このようなアプリケーションの1つの例は、モバイルバックホール（MBH）でのTEの使用です。図6に示すようにトポロジーを考えてみましょう（Agg 1 ... Agg nは集約ルーター、コア1 ...コアnはコアルーターです）。 +

+
+
+
+
+ 
+                              TE1 ----------->
+   +--------+    +------+    +-----+    +-------+    +------+  +---+
+   |Access  |----|Access|----|AGG 1|----|AGG N-1|----|Core 1|--|SR1|
+   |SubNode1|    |Node1 |    +-----+    +-------+    +------+  +---+
+   +--------+    +------+       | |         | ^          |
+       |   Access    |  Access  | AGG Ring 1| |          |
+       |  SubRing 1  |  Ring 1  | |         | |          |
+   +--------+    +------+    +-----+        | |          |
+   |Access  |    |Access|    |AGG 2|        | |          |
+   |SubNode2|    |Node2 |    +-----+        | |          |
+   +--------+    +------+       | |         | |          |
+       |             |          | |         | |          |
+       |             |          | +---TE2---|-+          |
+   +--------+    +------+    +-----+    +-------+    +------+  +---+
+   |Access  |    |Access|----|AGG 3|----| AGG N |----|Core N|--|SRn|
+   |SubNodeN|----|NodeN |    +-----+    +-------+    +------+  +---+
+   +--------+    +------+
+
+
+
+
+
+

+Figure 6: PCECC LB Use Case +

+
+
+

+図6：PCECC LBユースケース +

+
+
+
+
+

+This MBH architecture uses L2 access rings and sub-rings. L3 starts at the aggregation layer. For the sake of simplicity, the figure shows only one access sub-ring. The access ring and aggregation ring are connected by Nx10GE interfaces. The aggregation domain runs its own IGP. There are two egress routers (AGG N-1 and AGG N) that are connected to the Core domain (Core 1...Core N) via L2 interfaces. The Core also has connections to service routers; RSVP-TE or SR-TE is used for MPLS transport inside the ring. There could be at least two tunnels (one way) from each AGG router to egress AGG routers. There are also many L2 access rings connected to AGG routers. +

+
+
+

+このMBHアーキテクチャは、L2アクセスリングとサブリングを使用しています。L3は集約層から始まります。簡単にするために、この図は1つのアクセスサブリングのみを示しています。アクセスリングと集約リングは、NX10GEインターフェイスで接続されています。集約ドメインは独自のIGPを実行します。L2インターフェイスを介してコアドメイン（コア1 ...コアN）に接続されている2つの出力ルーター（AGG N-1とAGG N）があります。コアには、サービスルーターへの接続もあります。RSVP-TEまたはSR-TEは、リング内のMPLS輸送に使用されます。各AGGルーターから少なくとも2つのトンネル（1つの方法）がある可能性があります。AGGルーターに接続された多くのL2アクセスリングもあります。 +

+
+
+
+
+

+Service deployment is made by means of Layer 2 Virtual Private Networks (L2VPNs), Virtual Private LAN Services (VPLSs), Layer 3 Virtual Private Networks (L3VPNs), or Ethernet VPNs (EVPNs). Those services use MPLS TE (or SR-TE) as transport towards egress AGG routers. TE tunnels could be used as transport towards service routers in case of architecture based on seamless MPLS [MPLS-SEAMLESS]. +

+
+
+

+サービスの展開は、レイヤー2仮想プライベートネットワーク（L2VPNS）、仮想プライベートLANサービス（VPLSS）、レイヤー3仮想プライベートネットワーク（L3VPNS）、またはイーサネットVPN（EVPN）によって行われます。これらのサービスは、MPLS TE（またはSR-TE）を出力アグルーターへの輸送として使用します。TEトンネルは、シームレスMPL [MPLSシームレス]に基づいたアーキテクチャの場合、サービスルーターへの輸送として使用できます。 +

+
+
+
+
+

+Load Balancing (LB) between TE tunnels involves distributing network traffic across multiple TE tunnels to optimize the use of available network resources, enhance performance, and ensure reliability. Some common techniques include Equal-Cost Multipath (ECMP) and Unequal-Cost Multipath (UCMP) based on the BW of the TE tunnels. +

+
+
+

+TEトンネル間の負荷分散（LB）には、利用可能なネットワークリソースの使用を最適化し、パフォーマンスを向上させ、信頼性を確保するために、複数のTEトンネルにネットワークトラフィックを配布することが含まれます。いくつかの一般的な手法には、TEトンネルのBWに基づく等しいマルチパス（ECMP）および不平等なコストマルチパス（UCMP）が含まれます。 +

+
+
+
+
+

+There is a need to solve the following tasks: +

+
+
+

+次のタスクを解決する必要があります。 +

+
+
+
+
+

+* Perform automatic LB amongst TE tunnels according to current traffic loads. +

+
+
+

+* 現在のトラフィック負荷に応じて、トンネル間で自動LBを実行します。 +

+
+
+
+
+

+* Manage TE BW by guaranteeing BW for specific services (such as High-Speed Internet (HSI), IPTV, etc.) and enabling time-based BW reservation (such as Bandwidth on Demand (BoD)). +

+
+
+

+* 特定のサービス（高速インターネット（HSI）、IPTVなど）のBWを保証し、時間ベースのBW予約（帯域幅オンデマンド（BOD）など）を保証することにより、TE BWを管理します。 +

+
+
+
+
+

+* Simplify the development of TE tunnels by automation without any manual intervention. +

+
+
+

+* 手動で介入することなく、自動化によりTEトンネルの開発を簡素化します。 +

+
+
+
+
+

+* Provide flexibility for service router placement (anywhere in the network by the creation of transport LSPs to them). +

+
+
+

+* サービスルーターの配置に柔軟性を提供します（輸送LSPを作成することにより、ネットワーク内のどこでも）。 +

+
+
+
+
+

+In this section, the focus is on LB tasks. LB tasks could be solved by means of the PCECC in the following ways: +

+
+
+

+このセクションでは、LBタスクに焦点を当てています。LBタスクは、次の方法でPCECCによって解決できます。 +

+
+
+
+
+

+* Applications, network services, or operators can ask the SDN controller (PCECC) for LSP-based LB between AGG X and AGG N/AGG N-1 (egress AGG routers that have connections to the core). Each of these will have associated constraints (such as BW, inclusion or exclusion of specific links or nodes, number of paths, Objective Function (OF), need for disjoint LSP paths, etc.). +

+
+
+

+* アプリケーション、ネットワークサービス、またはオペレーターは、AGG XとAGG N/AGG N-1（コアに接続する出力AGGルーター）の間のLSPベースのLBについて、SDNコントローラー（PCECC）に尋ねることができます。これらのそれぞれには、関連する制約（BW、包含または特定のリンクまたはノードの除外、パス数、目的関数（）、馬鹿げたLSPパスの必要性など）があります。 +

+
+
+
+
+

+* The PCECC could calculate multiple (say N) LSPs according to given constraints. The calculation is based on the results of the OF [RFC5541], constraints, endpoints, same or different BW, different links (in case of disjoint paths), and other constraints. +

+
+
+

+* PCECCは、与えられた制約に従って複数の（たとえばn）LSPを計算できます。計算は、[RFC5541]の結果、制約、エンドポイント、同じまたは異なるBW、異なるリンク（不利な経路の場合）、およびその他の制約の結果に基づいています。 +

+
+
+
+
+

+* Depending on the given LSP PST, the PCECC will download instructions to the PCC. At this stage, it is assumed the PCECC is aware of the label space it controls and SID allocation and distribution is already done in the case of SR. +

+
+
+

+* 指定されたLSP PSTに応じて、PCECCはPCCに手順をダウンロードします。この段階では、PCECCが制御するラベル空間を認識しており、SIDの割り当てと分布はSRの場合にすでに行われています。 +

+
+
+
+
+

+* The PCECC will send a PCInitiate message [RFC8281] towards the ingress AGG X router (PCC) for each of N LSPs and receive a PCRpt message [RFC8231] back from PCCs. If the PST is a PCECC-SR, the PCECC will include a SID stack as per [RFC8664]. If the PST is set to "PCECC" type, then the PCECC will assign labels along the calculated path and set up the path by sending central controller instructions in a PCEP message to each node along the path of the LSP as per [RFC9050]. Then, the PCECC will send a PCUpd message to the ingress AGG X router with information about the new LSP. AGG X (PCC) will respond with a PCRpt with LSP status. +

+
+
+

+* PCECCは、N LSPのそれぞれのIngress Agg Xルーター（PCC）にPCInitiateメッセージ[RFC8281]を送信し、PCCSからPCRPTメッセージ[RFC8231]を受け取ります。PSTがPCECC-SRの場合、PCECCには[RFC8664]に従ってSIDスタックが含まれます。PSTが「PCECC」タイプに設定されている場合、PCECCは計算されたパスに沿ってラベルを割り当て、[RFC9050]に従ってLSPのパスに沿ってPCEPメッセージの中央コントローラー命令を送信してパスをセットアップします。次に、PCECCは、新しいLSPに関する情報を使用して、Ingress Agg XルーターにPCUPDメッセージを送信します。AGG X（PCC）は、LSPステータスのPCRPTで応答します。 +

+
+
+
+
+

+* AGG X as an ingress router now has N LSPs towards AGG N and AGG N-1, which are available for installation to the router's forwarding table and for LB traffic between them. Traffic distribution between those LSPs depends on the particular realization of the hash function on that router. +

+
+
+

+* IngressルーターとしてのAGG Xは、Agg NおよびAgg N-1に向かってn LSPを搭載しています。これは、ルーターの転送テーブルへの取り付けとそれらの間のLBトラフィックに使用できます。これらのLSP間のトラフィック分布は、そのルーター上のハッシュ関数の特定の実現に依存します。 +

+
+
+
+
+

+* Since the PCECC is aware of the Traffic Engineering Database (TED) (TE state) and the LSP Database (LSP-DB), it can manage and prevent possible over-subscriptions and limit the number of available load-balance states. Via a PCECC mechanism, the control can take quick actions into the network by directly provisioning the central control instructions. +

+
+
+

+* PCECCはトラフィックエンジニアリングデータベース（TED）（TEステート）とLSPデータベース（LSP-DB）を認識しているため、可能な過剰なサブスクリプションを管理および防止し、利用可能な負荷分散状態の数を制限できます。PCECCメカニズムを介して、コントロールは中央の制御命令を直接プロビジョニングすることにより、ネットワークに迅速なアクションを実行できます。 +

+
+
+
+
+
+3.5. PCECC and Inter-AS TE +
+
+
+
+3.5. PCECCおよびINTER-AS TE +
+
+
+
+
+

+There are various signalling options for establishing Inter-AS TE LSPs: contiguous TE LSPs [RFC5151], stitched TE LSPs [RFC5150], and nested TE LSPs [RFC4206]. +

+
+
+

+LSPSを確立するためのさまざまなシグナル伝達オプションがあります：連続したTe LSP [RFC5151]、ステッチされたTe LSP [RFC5150]、およびネストされたTe LSP [RFC4206]。 +

+
+
+
+
+

+The requirements for PCE-based Inter-AS setup [RFC5376] describe the approach and PCEP functionality that is needed for establishing Inter-AS TE LSPs. +

+
+
+

+PCEベースのASセットアップ[RFC5376]の要件は、テープ間の確立に必要なアプローチとPCEP機能を説明しています。 +

+
+
+
+
+

+[RFC5376] also gives an Inter-AS and Intra-AS PCE Reference Model (as shown in Figure 7) that is provided below in shortened form for the sake of simplicity. +

+
+
+

+[RFC5376]は、単純さのために以下に短縮された形式で提供されるPCE Inter-As-As-As-As-As-As-As-As-As-As-As-As-As-As-As-As-As-As-Asの参照モデル（図7を参照）も提供します。 +

+
+
+
+
+ 
+              Inter-AS       Inter-AS
+        PCC <-->PCE1<--------->PCE2
+         ::      ::             ::
+         ::      ::             ::
+         R1----ASBR1====ASBR3---R3---ASBR5
+         |   AS1 |        |    PCC     |
+         |       |        |    AS2     |
+         R2----ASBR2====ASBR4---R4---ASBR6
+         ::                     ::
+         ::                     ::
+      Intra-AS               Intra-AS
+         PCE3                   PCE4
+
+
+
+
+
+

+Figure 7: Shortened Form of the Inter-AS and Intra-AS PCE Reference Model +

+
+
+

+図7：AS間およびAS Intra-AS PCEリファレンスモデルの短縮形式 +

+
+
+
+
+

+The PCECC belonging to the different domains can cooperate to set up Inter-AS TE LSPs. The stateful Hierarchical PCE (H-PCE) mechanism [RFC8751] could also be used to establish a per-domain PCECC LSP first. These could be stitched together to form an Inter-AS TE LSP as described in [PCE-INTERDOMAIN]. +

+
+
+

+さまざまなドメインに属するPCECCは、協力してlspsとしてのセットアップを行うことができます。ステートフルな階層PCE（H-PCE）メカニズム[RFC8751]を使用して、最初にドメインごとのPCECC LSPを確立することもできます。これらを一緒に縫い合わせて、[PCE-interdomain]に記載されているように、lspとしています。 +

+
+
+
+
+

+For the sake of simplicity, here the focus is on a simplified Inter-AS case when both AS1 and AS2 belong to the same service provider administration. In that case, Inter-AS and Intra-AS PCEs could be combined in one single PCE if such combined PCE performance is enough to handle the load. The PCE will require interfaces (PCEP and BGP-LS) to both domains. PCECC redundancy mechanisms are described in [RFC8283]. Thus, routers (PCCs) in AS1 and AS2 can send PCEP messages towards the same PCECC. In Figure 8, the PCECC maintains a BGP-LS session with Route Reflectors (RRs) in each AS. This allows the RRs to redistribute routes to other BGP routers (clients) without requiring a full mesh. The RRs act as a BGP-LS Propagator, and the PCECC acts as a BGP-LS Consumer [RFC9552]. +

+
+
+

+簡単にするために、ここでは、AS1とAS2の両方が同じサービスプロバイダー管理に属している場合、単純化されたasの場合に焦点を当てています。その場合、そのような組み合わせたPCEパフォーマンスが負荷を処理するのに十分である場合、AS間およびAS Intra-AS PCEを1つのPCEで結合することができます。PCEには、両方のドメインにインターフェイス（PCEPおよびBGP-LS）が必要です。PCECC冗長性メカニズムは[RFC8283]で説明されています。したがって、AS1およびAS2のルーター（PCC）は、同じPCECCにPCEPメッセージを送信できます。図8では、PCECCはそれぞれのASにルートリフレクター（RRS）を使用したBGP-LSセッションを維持しています。これにより、RRSは完全なメッシュを必要とせずに他のBGPルーター（クライアント）にルートを再分配できます。RRSはBGP-LSプロパゲーターとして機能し、PCECCはBGP-LS消費者[RFC9552]として機能します。 +

+
+
+
+
+ 
+                +----BGP-LS------+ +------BGP-LS-----+
+                |                | |                 |
+         +-PCEP-|----++-+-------PCECC-----PCEP--++-+-|-------+
+       +-:------|----::-:-+                  +--::-:-|-------:---+
+       | :      |    :: : |                  |  :: : |       :   |
+       | :     RR1   :: : |                  |  :: : RR2     :   |
+       | v           v: : |      LSP1        |  :: v         v   |
+       | R1---------ASBR1=======================ASBR3--------R3  |
+       | |            v : |                  |  :v            |  |
+       | +----------ASBR2=======================ASBR4---------+  |
+       | |   Region 1   : |                  |  : Region 1    |  |
+       |----------------:-|                  |--:-------------|--|
+       | |              v |       LSP2       |  v             |  |
+       | +----------ASBR5=======================ASBR6---------+  |
+       |     Region 2     |                  |       Region 2    |
+       +------------------+ <--------------> +-------------------+
+           MPLS Domain 1          Inter-AS         MPLS Domain 2
+       <=======AS1=======>                    <========AS2=======>
+
+
+
+
+
+

+Figure 8: Particular Case of Inter-AS PCE +

+
+
+

+図8：PCE間の特定のケース +

+
+
+
+
+

+In the case of the PCECC Inter-AS TE scenario (as shown in Figure 8), where the service provider controls both domains (AS1 and AS2), each of them has its own IGP and MPLS transport. There is a need to set up Inter-AS LSPs for transporting different services on top of them (such as Voice, L3VPN, etc.). Inter-AS links with different capacities exist in several regions. The task is not only to provision those Inter-AS LSPs with given constraints but also to calculate the path and pre-setup the backup Inter-AS LSPs that will be used if the primary LSP fails. +

+
+
+

+PCECC Inter-AS TEシナリオ（図8に示すように）の場合、サービスプロバイダーは両方のドメイン（AS1とAS2）を制御します。それぞれが独自のIGPおよびMPLSトランスポートを備えています。それらの上にさまざまなサービスを輸送するために、LSP間（音声、L3VPNなど）を設定する必要があります。さまざまな容量を持つリンクをいくつかの地域に存在します。タスクは、それらのLSPを指定された制約で提供するだけでなく、パスを計算して、プライマリLSPが故障した場合に使用されるLSPとしてのバックアップ間局を事前に設定することでもあります。 +

+
+
+
+
+

+As per Figure 8, LSP1 from R1 to R3 goes via ASBR1 and ASBR3, and it is the primary Inter-AS LSP. LSP2 from R1 to R3 that goes via ASBR5 and ASBR6 is the backup one. In addition, there could also be a bypass LSP setup to protect against ASBR or Inter-AS link failures. +

+
+
+

+図8によると、R1からR3へのLSP1はASBR1およびASBR3を介して進み、LSPとしての主要なものです。R1からR3へのLSP2はASBR5を介してasbr6を介してバックアップされています。さらに、ASBRまたはAS間のリンク障害から保護するためのバイパスLSPセットアップもある可能性があります。 +

+
+
+
+
+

+After the addition of PCECC functionality to the PCE (SDN controller), the PCECC-based Inter-AS TE model should follow the PCECC use case for TE LSP including the requirements described in [RFC5376] with the following details: +

+
+
+

+PCE（SDNコントローラー）にPCECC機能を追加した後、PCECCベースのTE TEモデルは、[RFC5376]に記載されている要件を含むTE LSPのPCECCユースケースに次の詳細を含めて従う必要があります。 +

+
+
+
+
+

+* Since the PCECC needs to know the topology of both domains AS1 and AS2, the PCECC can utilize the BGP-LS peering with BGP routers (or RRs) in both domains. +

+
+
+

+* PCECCは両方のドメインAS1とAS2のトポロジーを知る必要があるため、PCECCは両方のドメインでBGPルーター（またはRRS）を使用してBGP-LSピアリングを利用できます。 +

+
+
+
+
+

+* The PCECC needs to establish PCEP connectivity with all routers in both domains (see also Section 4 of [RFC5376]). +

+
+
+

+* PCECCは、両方のドメインのすべてのルーターでPCEP接続を確立する必要があります（[RFC5376]のセクション4も参照）。 +

+
+
+
+
+

+* After the operator's application or service orchestrator creates a request for tunnel creation of a specific service, the PCECC will receive that request via the Northbound Interface (NBI) (note that the NBI type is implementation-dependent; it could be NETCONF/ YANG, REST, etc.). Then, the PCECC will calculate the optimal path based on the OF and given constraints (i.e., PST, BW, etc.). These constraints include those from [RFC5376], such as priority, AS sequence, preferred ASBR, disjoint paths, and protection type. In this step, we will have two paths: "R1-ASBR1-ASBR3-R3, R1-ASBR5-ASBR6-R3". +

+
+
+

+* オペレーターのアプリケーションまたはサービスオーケストレーターが特定のサービスのトンネル作成のリクエストを作成した後、PCECCはノースバウンドインターフェイス（NBI）を介してそのリクエストを受け取ります（NBIタイプは実装依存であることに注意してください。、など）。次に、PCECCは、ofおよび与えられた制約に基づいて最適なパスを計算します（つまり、PST、BWなど）。これらの制約には、優先度など、[RFC5376]の[RFC5376]の制約、優先ASBR、馬鹿げたパス、保護タイプなどが含まれます。このステップでは、「R1-ASBR1-ASBR3-R3、R1-ASBR5-ASBR6-R3」という2つのパスがあります。 +

+
+
+
+
+

+* The PCECC will use central control download instructions to the PCC based on the PST. At this stage, it is assumed the PCECC is aware of the label space it controls, and in the case of SR, the SID allocation and distribution is already done. +

+
+
+

+* PCECCは、PSTに基づいてPCCにCentral Controlのダウンロード命令を使用します。この段階では、PCECCが制御するラベル空間を認識していると想定されており、SRの場合、SIDの割り当てと分布はすでに行われています。 +

+
+
+
+
+

+* The PCECC will send a PCInitiate message [RFC8281] towards the ingress router R1 (PCC) in AS1 and receive the PCRpt message [RFC8231] back from it. +

+
+
+

+* PCECCは、AS1のIngressルーターR1（PCC）にPCInitiateメッセージ[RFC8281]を送信し、PCRPTメッセージ[RFC8231]を受け取ります。 +

+
+
+
+
+

+- If the PST is SR-MPLS, the PCECC will include the SID stack as per [RFC8664]. Optionally, a BSID or BGP Peering-SID [RFC9087] can also be included on the AS boundary. The backup SID stack can be installed at ingress R1, but more importantly, each node along the SR path could also do the local protection just based on the top segment. +

+
+
+

+- PSTがSR-MPLSの場合、PCECCには[RFC8664]に従ってSIDスタックが含まれます。オプションで、BSIDまたはBGP Peering-SID [RFC9087]もAS境界に含めることができます。バックアップSIDスタックはIngress R1にインストールできますが、さらに重要なことに、SRパスに沿った各ノードは、上部セグメントだけに基づいてローカル保護を行うこともできます。 +

+
+
+
+
+

+- If the PST is a PCECC, the PCECC will assign labels along the calculated paths ("R1-ASBR1-ASBR3-R3", "R1-ASBR5-ASBR6-R3") and sets up the path by sending central controller instructions in a PCEP message to each node along the path of the LSPs as per [RFC9050]. After these steps, the PCECC will send a PCUpd message to the ingress R1 router with information about new LSPs and R1 will respond by a PCRpt with LSP(s) status. +

+
+
+

+- PSTがPCECCの場合、PCECCは計算されたパスに沿ってラベルを割り当てます（ "R1-ASBR1-ASBR3-R3"、 "R1-ASBR5-ASBR6-R3"）。[RFC9050]に従って、LSPのパスに沿った各ノードへのメッセージ。これらの手順の後、PCECCは新しいLSPに関する情報を使用してPCUPDメッセージをIngress R1ルーターに送信し、R1はLSP（S）ステータスのPCRPTで応答します。 +

+
+
+
+
+

+* After that step, R1 now has primary and backup TEs (LSP1 and LSP2) towards R3. It is up to the router implementation for how to switchover to backup LSP2 if LSP1 fails. +

+
+
+

+* そのステップの後、R1にはR3に向かってプライマリおよびバックアップTE（LSP1およびLSP2）があります。LSP1が失敗した場合、LSP2をバックアップする方法のルーターの実装次第です。 +

+
+
+
+
+
+3.6. PCECC for Multicast LSPs +
+
+
+
+3.6. マルチキャストLSPのPCECC +
+
+
+
+
+

+The multicast LSPs can be set up via the RSVP-TE P2MP or Multipoint LDP (mLDP) protocols. The setup of these LSPs may require manual configurations and complex signalling when the protection is considered. By using the PCECC solution, the multicast LSP can be computed and set up through a centralized controller that has the full picture of the topology and BW usage for each link. It not only reduces the complex configurations comparing the distributed RSVP-TE P2MP or mLDP signalling, but also it can compute the disjoint primary path and secondary P2MP path efficiently. +

+
+
+

+マルチキャストLSPは、RSVP-TE P2MPまたはマルチポイントLDP（MLDP）プロトコルを介してセットアップできます。これらのLSPのセットアップでは、保護を考慮した場合、手動構成と複雑なシグナル伝達が必要になる場合があります。PCECCソリューションを使用することにより、マルチキャストLSPを計算して、各リンクのトポロジとBW使用の全体像を備えた集中コントローラーを介してセットアップできます。分散型RSVP-TE P2MPまたはMLDPシグナルを比較する複雑な構成を減らすだけでなく、馬鹿げたプライマリパスとセカンダリP2MPパスを効率的に計算することもできます。 +

+
+
+
+
+
+3.6.1. PCECC for the Setup of P2MP/MP2MP LSPs +
+
+
+
+3.6.1. P2MP/MP2MP LSPのセットアップ用PCECC +
+
+
+
+
+

+It is assumed the PCECC is aware of the label space it controls for all nodes and makes allocations accordingly. +

+
+
+

+PCECCは、すべてのノードに対して制御するラベルスペースを認識しており、それに応じて割り当てを行うと想定されています。 +

+
+
+
+
+ 
+                          +----------+
+                          |    R1    | Root Node of the multicast LSP
+                          +----------+
+                              |9000 (link0)
+                          +----------+
+           Transit Node   |    R2    |
+           branch         +----------+
+                          *  |   *  *
+                     9001*   |   *   *9002
+                  link1 *    |   *    *link2
+           +-----------+     |   *     +-----------+
+           |    R4     |     |   *     |    R5     | Transit Nodes
+           +-----------+     |   *     +-----------+
+                      *      |   *      *     +
+                   9003*     |   *     *      +9004
+                  link3 *    |   *    *       +link4
+                        +-----------+  +-----------+
+                        |    R3     |  |    R6     | Leaf Node
+                        +-----------+  +-----------+
+                         9005| link5
+                        +-----------+
+                        |    R8     | Leaf Node
+                        +-----------+
+
+
+
+
+
+

+Figure 9: Using a PCECC for the Setup of P2MP/MP2MP LSPs +

+
+
+

+図9：P2MP/MP2MP LSPのセットアップにPCECCを使用する +

+
+
+
+
+

+The P2MP examples (based on Figure 9) are explained here, where R1 is the root and the routers R8 and R6 are the leaves. +

+
+
+

+P2MPの例（図9に基づく）はここで説明されています。ここで、R1はルートであり、ルーターR8とR6は葉です。 +

+
+
+
+
+

+* Based on the P2MP path computation request/delegation or PCE initiation, the PCECC receives the request with constraints and optimization criteria. +

+
+
+

+* P2MPパス計算要求/委任またはPCEの開始に基づいて、PCECCは制約と最適化基準でリクエストを受信します。 +

+
+
+
+
+

+* The PCECC will calculate the optimal P2MP path according to given constraints (i.e., BW). +

+
+
+

+* PCECCは、指定された制約（つまり、BW）に従って最適なP2MPパスを計算します。 +

+
+
+
+
+

+* The PCECC will provision each node along the path and assign incoming and outgoing labels from R1 to {R6, R8} with the path as "R1-link0-R2-link2-R5-link4-R6" and "R1-link0-R2-link1-R4-link3-R3-link5-R8": +

+
+
+

+* PCECCは、パスに沿って各ノードをプロビジョニングし、R1から{R6、R8}に着信ラベルと発信ラベルを「R1-Link0-R2-Link2-Link4-R6」および「R1-Link0-R2-を割り当てます。Link1-R4-Link3-R3-Link5-R8 "： +

+
+
+
+
+

+- R1: Outgoing label 9000 on link0 +

+
+
+

+- R1：Link0の発信ラベル9000 +

+
+
+
+
+

+- R2: Incoming label 9000 on link0 +

+
+
+

+- R2：Link0の着信ラベル9000 +

+
+
+
+
+

+- R2: Outgoing label 9001 on link1 (*) +

+
+
+

+- R2：link1の発信ラベル9001（*） +

+
+
+
+
+

+- R2: Outgoing label 9002 on link2 (*) +

+
+
+

+- R2：link2の発信ラベル9002（*） +

+
+
+
+
+

+- R5: Incoming label 9002 on link2 +

+
+
+

+- R5：リンク2の着信ラベル9002 +

+
+
+
+
+

+- R5: Outgoing label 9004 on link4 +

+
+
+

+- R5：リンク4の発信ラベル9004 +

+
+
+
+
+

+- R6: Incoming label 9004 on link4 +

+
+
+

+- R6：リンク4の着信ラベル9004 +

+
+
+
+
+

+- R4: Incoming label 9001 on link1 +

+
+
+

+- R4：リンク1の着信ラベル9001 +

+
+
+
+
+

+- R4: Outgoing label 9003 on link3 +

+
+
+

+- R4：リンク3の発信ラベル9003 +

+
+
+
+
+

+- R3: Incoming label 9003 on link3 +

+
+
+

+- R3：リンク3の着信ラベル9003 +

+
+
+
+
+

+- R3: Outgoing label 9005 on link5 +

+
+
+

+- R3：リンク5の発信ラベル9005 +

+
+
+
+
+

+- R8: Incoming label 9005 on link5 +

+
+
+

+- R8：リンク5の着信ラベル9005 +

+
+
+
+
+

+* This can also be represented as: {R1, 6000}, {6000, R2, {9001, 9002}}, {9001, R4, 9003}, {9002, R5, 9004} {9003, R3, 9005}, {9004, R6}, {9005, R8}. The main difference (*) is in the branch node instruction at R2, where two copies of a packet are sent towards R4 and R5 with 9001 and 9002 labels, respectively. +

+
+
+

+* これは、{r1、6000}、{6000、r2、{9001、9002}}、{9001、r4、9003}、{9002、r5、9004} {9003、r3、9005}、{9004、r6}、{9005、r8}。主な違い（*）は、R2のブランチノード命令で、パケットの2つのコピーがそれぞれ9001と9002のラベルでR4とR5に送られます。 +

+
+
+
+
+

+The packet forwarding involves the following: +

+
+
+

+パケット転送には次のものが含まれます。 +

+
+
+
+
+

+Step 1. R1 sends a packet to R2 simply by pushing the label of 9000 to the packet. +

+
+
+

+ステップ1。R19000のラベルをパケットに押し込むだけで、パケットをR2に送信します。 +

+
+
+
+
+

+Step 2. When R2 receives the packet with label 9000, it will forward it to R4 by swapping label 9000 to 9001. At the same time, it will replicate the packet and swap the label 9000 to 9002 and forward it to R5. +

+
+
+

+ステップ2。R2がラベル9000でパケットを受信すると、ラベル9000から9001を交換してR4に転送します。同時に、パケットを複製し、ラベル9000から9002に交換し、R5に転送します。 +

+
+
+
+
+

+Step 3. When R4 receives the packet with label 9001, it will forward it to R3 by swapping 9001 to 9003. When R5 receives the packet with the label 9002, it will forward it to R6 by swapping 9002 to 9004. +

+
+
+

+ステップ3。R4がラベル9001でパケットを受信すると、9001を交換してR3に転送します。R5がラベル9002でパケットを受信すると、9002を交換してR6に転送します。 +

+
+
+
+
+

+Step 4. When R3 receives the packet with label 9003, it will forward it to R8 by swapping it to 9005. When R5 receives the packet with label 9002, it will be swapped to 9004 and sent to R6. +

+
+
+

+ステップ4。R3がラベル9003でパケットを受信すると、R8を9005に交換してR8に転送します。R5がラベル9002でパケットを受信すると、9004に交換され、R6に送信されます。 +

+
+
+
+
+

+Step 5. When R8 receives the packet with label 9005, it will pop the label. When R6 receives the packet with label 9004, it will pop the label. +

+
+
+

+ステップ5。R8がラベル9005でパケットを受信すると、ラベルがポップされます。R6がラベル9004でパケットを受信すると、ラベルがポップされます。 +

+
+
+
+
+
+3.6.2. PCECC for the End-to-End Protection of P2MP/MP2MP LSPs +
+
+
+
+3.6.2. P2MP/MP2MP LSPのエンドツーエンド保護のためのPCECC +
+
+
+
+
+

+This section describes the end-to-end managed path protection service as well as the local protection with the operation management in the PCECC network for the P2MP/MP2MP LSP. +

+
+
+

+このセクションでは、エンドツーエンドのマネージドパス保護サービスと、P2MP/MP2MP LSPのPCECCネットワークの操作管理を伴うローカル保護について説明します。 +

+
+
+
+
+

+An end-to-end protection principle can be applied for computing backup P2MP or MP2MP LSPs. During the computation of the primary multicast trees, the PCECC could also take the computation of a secondary tree into consideration. A PCECC could compute the primary and backup P2MP (or MP2MP) LSPs together or sequentially. +

+
+
+

+バックアップP2MPまたはMP2MP LSPを計算するために、エンドツーエンドの保護原理を適用できます。プライマリマルチキャストツリーの計算中、PCECCは二次ツリーの計算を考慮に入れることもできます。PCECCは、プライマリおよびバックアップP2MP（またはMP2MP）LSPを一緒にまたは順次計算できます。 +

+
+
+
+
+ 
+                               +----+  +----+
+              Root Node of LSP | R1 |--| R11|
+                               +----+  +----+
+                                 /         +
+                              10/           +20
+                               /             +
+                       +----------+        +-----------+
+        Transit Node   |    R2    |        |     R3    |
+                       +----------+        +-----------+
+                         |        \       +         +
+                         |         \     +          +
+                       10|        10\   +20       20+
+                         |           \ +            +
+                         |            \             +
+                         |           + \            +
+                       +-----------+      +-----------+ Leaf Nodes
+                       |    R4     |      |    R5     | (Downstream LSR)
+                       +-----------+      +-----------+
+
+
+
+
+
+

+Figure 10: PCECC for the End-to-End Protection of P2MP/MP2MP LSPs +

+
+
+

+図10：P2MP/MP2MP LSPのエンドツーエンド保護のためのPCECC +

+
+
+
+
+

+In Figure 10, when the PCECC sets up the primary multicast tree from the root node R1 to the leaves, which is R1->R2->{R4, R5}, it can set up the backup tree at the same time, which is R1->R11->R3->{R4, R5}. Both of them (the primary forwarding tree and secondary forwarding tree) will be downloaded to each router along the primary path and the secondary path. The traffic will be forwarded through the R1->R2->{R4, R5} path normally, but when a node in the primary tree fails (say R2), the root node R1 will switch the flow to the backup tree, which is R1->R11->R3->{R4, R5}. By using the PCECC, path computation, label downloading, and finally forwarding can be done without the complex signalling used in the P2MP RSVP-TE or mLDP. +

+
+
+

+図10では、PCECCがルートノードR1から葉、つまりR1-> {r4、R5}のプライマリマルチキャストツリーをセットアップすると、バックアップツリーを同時にセットアップできます。r1-> r11-> r3-> {r4、r5}。両方（主要な転送ツリーとセカンダリ転送ツリー）は、プライマリパスとセカンダリパスに沿って各ルーターにダウンロードされます。トラフィックはR1-> R2-> {r4、R5}パスを介して正常に転送されますが、プライマリツリーのノードが失敗すると（たとえばR2）、ルートノードR1はフローをバックアップツリーに切り替えます。r1-> r11-> r3-> {r4、r5}。PCECC、PATH計算、ラベルのダウンロード、および最終的に転送を使用することにより、P2MP RSVP-TEまたはMLDPで使用される複雑なシグナルを使用せずに実行できます。 +

+
+
+
+
+
+3.6.3. PCECC for the Local Protection of P2MP/MP2MP LSPs +
+
+
+
+3.6.3. P2MP/MP2MP LSPの局所保護のためのPCECC +
+
+
+
+
+

+In this section, we describe the local protection service in the PCECC network for the P2MP/MP2MP LSP. +

+
+
+

+このセクションでは、P2MP/MP2MP LSPのPCECCネットワークのローカル保護サービスについて説明します。 +

+
+
+
+
+

+While the PCECC sets up the primary multicast tree, it can also build the backup LSP between the Point of Local Repair (PLR), protected node, and Merge Points (MPs) (the downstream nodes of the protected node). In the cases where the amount of downstream nodes is huge, this mechanism can avoid unnecessary packet duplication on the PLR and protect the network from traffic congestion risks. +

+
+
+

+PCECCはプライマリマルチキャストツリーをセットアップしますが、ローカル修理ポイント（PLR）、保護ノード、マージポイント（MPS）（保護ノードの下流ノード）の間にバックアップLSPを構築することもできます。ダウンストリームノードの量が膨大な場合、このメカニズムはPLRの不必要なパケットの複製を回避し、交通渋滞のリスクからネットワークを保護することができます。 +

+
+
+
+
+ 
+                               +------------+
+                               |     R1     | Root Node
+                               +------------+
+                                      .
+                                      .
+                                      .
+                               +------------+ Point of Local Repair /
+                               |     R10     | Switchover Point
+                               +------------+ (Upstream LSR)
+                                 /         +
+                              10/           +20
+                               /             +
+                       +----------+        +-----------+
+        Protected Node |    R20   |        |     R30   |
+                       +----------+        +-----------+
+                         |        \       +         +
+                         |         \     +          +
+                       10|        10\   +20       20+
+                         |           \ +            +
+                         |            \             +
+                         |           + \            +
+                       +-----------+      +-----------+ Merge Point
+                       |    R40    |      |    R50    | (Downstream LSR)
+                       +-----------+      +-----------+
+                             .                  .
+                             .                  .
+
+
+
+
+
+

+Figure 11: PCECC for the Local Protection of P2MP/MP2MP LSPs +

+
+
+

+図11：P2MP/MP2MP LSPの局所保護のためのPCECC +

+
+
+
+
+

+In Figure 11, when the PCECC sets up the primary multicast path around the PLR node R10 to protect node R20, which is R10->R20->{R40, R50}, it can set up the backup path R10->R30->{R40, R50} at the same time. Both the primary forwarding path and the secondary bypass forwarding path will be downloaded to each router along the primary path and the secondary bypass path. The traffic will be forwarded through the R10->R20->{R40, R50} path normally, and when there is a node failure for node R20, the PLR node R10 will switch the flow to the backup path, which is R10->R30->{R40, R50}. By using the PCECC, path computation, label downloading, and finally forwarding can be done without the complex signalling used in the P2MP RSVP-TE or mLDP. +

+
+
+

+図11では、PCECCがPLRノードR10の周りのプライマリマルチキャストパスを設定して、r10-> r20-> {r40、r50}です。バックアップパスr10-> r30->{r40、r50}同時に。一次転送パスとセカンダリバイパス転送パスの両方が、プライマリパスとセカンダリバイパスパスに沿った各ルーターにダウンロードされます。トラフィックはR10-> R20-> {R40、R50}パスを介して正常に転送され、ノードR20にノード障害がある場合、PLRノードR10はフローをバックアップパスに切り替えます。r30-> {r40、r50}。PCECC、PATH計算、ラベルのダウンロード、および最終的に転送を使用することにより、P2MP RSVP-TEまたはMLDPで使用される複雑なシグナルを使用せずに実行できます。 +

+
+
+
+
+
+3.7. PCECC for Traffic Classification +
+
+
+
+3.7. トラフィック分類のためのPCECC +
+
+
+
+
+

+As described in [RFC8283], traffic classification is an important part of traffic engineering. It is the process of looking into a packet to determine how it should be treated while it is forwarded through the network. It applies in many scenarios, including the following: +

+
+
+

+[RFC8283]で説明されているように、トラフィック分類はトラフィックエンジニアリングの重要な部分です。これは、ネットワークを介して転送されたときにどのように処理するかを決定するためにパケットを調べるプロセスです。以下を含む多くのシナリオに適用されます。 +

+
+
+
+
+

+* MPLS traffic engineering (where it determines what traffic is forwarded into which LSPs), +

+
+
+

+* MPLSトラフィックエンジニアリング（LSPにどのトラフィックが転送されるかを決定する場所）、 +

+
+
+
+
+

+* SR (where it is used to select which set of forwarding instructions (SIDs) to add to a packet), and +

+
+
+

+* SR（パケットに追加する転送命令のセット（SIDS）を選択するために使用される場合）、および +

+
+
+
+
+

+* SFC (where it indicates how a packet should be forwarded across which service function path). +

+
+
+

+* SFC（ここで、パケットがどのサービス機能パスを越えて転送するかを示します）。 +

+
+
+
+
+

+In conjunction with traffic engineering, traffic classification is an important enabler for LB. Traffic classification is closely linked to the computational elements of planning for the network functions because it determines how traffic is balanced and distributed through the network. Therefore, selecting what traffic classification mechanism should be performed by a router is an important part of the work done by a PCECC. +

+
+
+

+交通工学と併せて、トラフィック分類はLBにとって重要なイネーブラーです。トラフィックの分類は、ネットワークを介してトラフィックのバランスと分布の方法を決定するため、ネットワーク機能の計画の計算要素に密接にリンクしています。したがって、ルーターによって実行されるトラフィック分類メカニズムを選択することは、PCECCによって行われた作業の重要な部分です。 +

+
+
+
+
+

+The description of traffic flows by the combination of multiple Flow Specification components and their dissemination as traffic Flow Specifications is described for BGP in [RFC8955]. When a PCECC is used to initiate tunnels (such as TE LSPs or SR paths) using PCEP, it is important that the headend of the tunnels understands what traffic to place on each tunnel. [RFC9168] specifies a set of extensions to PCEP to support the dissemination of Flow Specification components where the instructions are passed from the PCECC to the routers using PCEP. +

+
+
+

+複数のフロー仕様コンポーネントの組み合わせと交通流の仕様としての普及によるトラフィックフローの説明は、[RFC8955]のBGPについて説明されています。PCEPを使用してPCECCを使用してトンネル（TE LSPやSRパスなど）を開始する場合、トンネルのヘッドエンドが各トンネルに配置するトラフィックを理解することが重要です。[RFC9168]は、PCEPを使用してPCECCからルーターに命令が渡されるフロー仕様コンポーネントの普及をサポートするために、PCEPの拡張セットを指定します。 +

+
+
+
+
+

+Along with traffic classification, there are a few more questions about the tunnels set up by the PCECC that need to be considered: +

+
+
+

+トラフィック分類に加えて、PCECCによって設定されたトンネルについて、考慮する必要があるトンネルについてさらにいくつかの質問があります。 +

+
+
+
+
+

+* how to use it, +

+
+
+

+* それを使用する方法、 +

+
+
+
+
+

+* whether it is a virtual link, +

+
+
+

+* 仮想リンクかどうか、 +

+
+
+
+
+

+* whether to advertise it in the IGP as a virtual link, and +

+
+
+

+* IGPで仮想リンクとして宣伝するかどうか、そして +

+
+
+
+
+

+* what bits of this information to signal to the tail end. +

+
+
+

+* この情報のビットは、テールエンドに合図します。 +

+
+
+
+
+

+These are out of the scope of this document. +

+
+
+

+これらはこのドキュメントの範囲外です。 +

+
+
+
+
+
+3.8. PCECC for SFC +
+
+
+
+3.8. SFCのPCECC +
+
+
+
+
+

+Service Function Chaining (SFC) is described in [RFC7665]. It is the process of directing traffic in a network such that it passes through specific hardware devices or virtual machines (known as service function nodes) that can perform particular desired functions on the traffic. The set of functions to be performed and the order in which they are to be performed is known as a service function chain. The chain is enhanced with the locations at which the service functions are to be performed to derive a Service Function Path (SFP). Each packet is marked as belonging to a specific SFP, and that marking lets each successive service function node know which functions to perform and to which service function node to send the packet next. To operate an SFC network, the service function nodes must be configured to understand the packet markings, and the edge nodes must be told how to mark packets entering the network. Additionally, it may be necessary to establish tunnels between service function nodes to carry the traffic. Planning an SFC network requires LB between service function nodes and traffic engineering across the network that connects them. As per [RFC8283], these are operations that can be performed by a PCECC, and that controller can use PCEP to program the network and install the service function chains and any required tunnels. +

+
+
+

+サービス関数チェーン（SFC）は[RFC7665]で説明されています。これは、トラフィックで特定の目的の機能を実行できる特定のハードウェアデバイスまたは仮想マシン（サービス関数ノードとして知られている）を通過するように、ネットワーク内のトラフィックを向けるプロセスです。実行される関数のセットとそれらが実行される順序は、サービス関数チェーンとして知られています。チェーンは、サービス関数パス（SFP）を導出するためにサービス機能を実行する場所で強化されます。各パケットは特定のSFPに属するものとしてマークされており、そのマーキングにより、各連続するサービス機能ノードが実行する機能と、次にパケットを送信するサービス機能ノードを知ることができます。SFCネットワークを操作するには、パケットマークを理解するようにサービス関数ノードを構成する必要があり、エッジノードにネットワークに入るパケットをマークする方法を指定する必要があります。さらに、トラフィックを運ぶためにサービス関数ノード間にトンネルを確立する必要がある場合があります。SFCネットワークの計画には、サービス機能ノードとそれらを接続するネットワーク全体のトラフィックエンジニアリングの間のLBが必要です。[RFC8283]によると、これらはPCECCで実行できる操作であり、コントローラーはPCEPを使用してネットワークをプログラムし、サービス関数チェーンと必要なトンネルをインストールできます。 +

+
+
+
+
+

+A possible mechanism could add support for SFC-based central control instructions. The PCECC will be able to instruct each Service Function Forwarder (SFF) along the SFP. +

+
+
+

+考えられるメカニズムは、SFCベースの中央制御命令のサポートを追加できます。PCECCは、SFPに沿って各Service Function Forwarder（SFF）を指示することができます。 +

+
+
+
+
+

+* Service Path Identifier (SPI): Uniquely identifies an SFP. +

+
+
+

+* サービスパス識別子（SPI）：SFPを一意に識別します。 +

+
+
+
+
+

+* Service Index (SI): Provides location within the SFP. +

+
+
+

+* サービスインデックス（SI）：SFP内の場所を提供します。 +

+
+
+
+
+

+* Provide SFC Proxy handling instruction. +

+
+
+

+* SFCプロキシ処理命令を提供します。 +

+
+
+
+
+

+The PCECC can play the role of setting the traffic classification rules (as per Section 3.7) at the classifier to impose the Network Service Header (NSH) [RFC8300]. It can also download the forwarding instructions to each SFF along the way so that they could process the NSH and forward accordingly. This includes instructions for the service classifier that handles the context header, metadata, etc. This metadata/context is shared amongst SFs and classifiers, between SFs, and between external systems (such as a PCECC) and SFs. As described in [RFC7665], the SFC encapsulation enables the sharing of metadata/context information along the SFP. +

+
+
+

+PCECCは、ネットワークサービスヘッダー（NSH）[RFC8300]を課すために、分類器にトラフィック分類ルール（セクション3.7に従って）を設定する役割を果たすことができます。また、途中で各SFFへの転送命令をダウンロードして、NSHを処理してそれに応じて転送できるようにすることもできます。これには、コンテキストヘッダー、メタデータなどを処理するサービス分類器の指示が含まれます。このメタデータ/コンテキストは、SFSおよび分類器間、SFS間、および外部システム（PCECCなど）およびSFS間で共有されます。[RFC7665]で説明されているように、SFCカプセル化により、SFPに沿ったメタデータ/コンテキスト情報の共有が可能になります。 +

+
+
+
+
+

+It is also possible to support SFC with SR in conjunction with or without an NSH such as described in [RFC9491] and [SR-SERVICE]. PCECC techniques can also be used for service-function-related segments and SR service policies. +

+
+
+

+また、[RFC9491]および[SR-Service]に記載されているようなNSHの有無にかかわらず、SRをSRでサポートすることも可能です。PCECCテクニックは、サービス機能関連のセグメントやSRサービスポリシーにも使用できます。 +

+
+
+
+
+
+3.9. PCECC for Native IP +
+
+
+
+3.9. ネイティブIP用のPCECC +
+
+
+
+
+

+[RFC8735] describes the scenarios and simulation results for the "Centralized Control Dynamic Routing (CCDR)" solution, which integrates the advantage of using distributed protocols (IGP/BGP) and the power of a centralized control technology (PCE/SDN), providing traffic engineering for native IP networks. [RFC8821] defines the framework for CCDR traffic engineering within a native IP network, using multiple BGP sessions and a PCE as the centralized controller. It requires the PCECC to send the instructions to the PCCs to build multiple BGP sessions, distribute different prefixes on the established BGP sessions, and assign the different paths to the BGP next hops. The PCEP is used to transfer the key parameters between the PCE and the underlying network devices (PCC) using the PCECC technique. The central control instructions from the PCECC to PCC will identify which prefix should be advertised on which BGP session. There are PCEP extensions defined in [PCEP-NATIVE] for it. +

+
+
+

+[RFC8735]は、分布プロトコル（IGP/BGP）を使用する利点と集中制御技術（PCE/SDN）の能力を統合し、提供し、提供する、「集中制御動的ルーティング（CCDR）」ソリューションのシナリオとシミュレーション結果を説明します。ネイティブIPネットワークのトラフィックエンジニアリング。[RFC8821]は、複数のBGPセッションとPCEを中央コントローラーとして使用して、ネイティブIPネットワーク内のCCDRトラフィックエンジニアリングのフレームワークを定義します。PCECCは、複数のBGPセッションを構築し、確立されたBGPセッションで異なるプレフィックスを配布し、BGPの次のホップに異なるパスを割り当てるために、PCCSに指示を送信する必要があります。PCEPは、PCECC技術を使用して、PCEと基礎となるネットワークデバイス（PCC）の間に重要なパラメーターを転送するために使用されます。PCECCからPCCへの中央制御命令は、どのBGPセッションでどのプレフィックスを宣伝するかを特定します。[pcep-native]で定義されているPCEP拡張機能があります。 +

+
+
+
+
+ 
+                                  +------+
+                       +----------+ PCECC+-------+
+                       |          +------+       |
+                       |                         |
+                  PCEP | BGP Session 1(lo11/lo21)| PCEP
+                       +-------------------------+
+                       |                         |
+                       | BGP Session 2(lo12/lo22)|
+                       +-------------------------+
+   PF12                |                         |                 PF22
+   PF11                |                         |                 PF21
+   +---+         +-----+-----+             +-----+-----+           +---+
+   |SW1+---------+(lo11/lo12)+-------------+(lo21/lo22)+-----------+SW2|
+   +---+         |    R1     +-------------+    R2     |           +---+
+                 +-----------+             +-----------+
+
+
+
+
+
+

+Figure 12: PCECC for Native IP +

+
+
+

+図12：ネイティブIPのPCECC +

+
+
+
+
+

+In the case as shown in Figure 12, the PCECC will instruct both R1 and R2 how to form BGP sessions with each other via PCEP and which IP prefixes need to be advertised via which BGP session. +

+
+
+

+図12に示すように、PCECCはR1とR2の両方に、PCEPを介してBGPセッションを互いに形成する方法と、どのBGPセッションを介して宣伝する必要があるかを指示します。 +

+
+
+
+
+
+3.10. PCECC for BIER +
+
+
+
+3.10. ビア用PCECC +
+
+
+
+
+

+Bit Index Explicit Replication (BIER) [RFC8279] defines an architecture where all intended multicast receivers are encoded as a BitMask in the multicast packet header within different encapsulations. A router that receives such a packet will forward that packet based on the bit position in the packet header towards the receiver(s) following a precomputed tree for each of the bits in the packet. Each receiver is represented by a unique bit in the BitMask. +

+
+
+

+ビットインデックス明示的複製（BIER）[RFC8279]は、さまざまなカプセル内のマルチキャストパケットヘッダーのビットマスクとしてエンコードされるすべてのマルチキャストレシーバーがエンコードされるアーキテクチャを定義します。このようなパケットを受信するルーターは、パケットヘッダー内のビット位置に基づいてパケットを転送し、パケット内の各ビットの事前計算ツリーに続いてレシーバーに向かって進みます。各レシーバーは、ビットマスクのユニークなビットで表されます。 +

+
+
+
+
+

+BIER-TE [RFC9262] shares architecture and packet formats with BIER. BIER-TE forwards and replicates packets based on a BitString in the packet header, but every BitPosition of the BitString of a BIER-TE packet indicates one or more adjacencies. BIER-TE paths can be derived from a PCE and used at the ingress (a possible mechanism is described in [PCEP-BIER]). +

+
+
+

+Bier-TE [RFC9262]は、Bierとアーキテクチャとパケット形式を共有しています。パケットヘッダーのビットストリングに基づいて、ビアテをフォワードして再現しますが、ビアテパケットのビットストリングのすべてのビットポジションは、1つ以上の隣接を示します。Bier-TEパスはPCEから導出され、イングレスで使用できます（可能なメカニズムは[PCEP-Bier]で説明されています）。 +

+
+
+
+
+

+The PCECC mechanism could be used for the allocation of bits for the BIER router for BIER as well as for the adjacencies for BIER-TE. PCECC-based controllers can use PCEP to instruct the BIER-capable routers on the meaning of the bits as well as other fields needed for BIER encapsulation. The PCECC could be used to program the BIER router with various parameters used in the BIER encapsulation (such as BIER sub-domain-id, BFR-id, etc.) for both node and adjacency. +

+
+
+

+PCECCメカニズムは、ビアーのビアルーターのビットの割り当てと、ビアテの隣接に使用できます。PCECCベースのコントローラーは、PCEPを使用して、ビットの意味とビアカプセル化に必要な他のフィールドについて、ビア対応ルーターに指示することができます。PCECCを使用して、ノードと隣接の両方について、Bierカプセル化（Bier Sub-Domain-ID、BFR-IDなど）で使用されるさまざまなパラメーターを使用してBierルーターをプログラムできます。 +

+
+
+
+
+

+A possible way to use the PCECC and PCEP extension is described in [PCECC-BIER]. +

+
+
+

+PCECCおよびPCEP拡張機能を使用する可能性のある方法は、[PCECC-Bier]で説明されています。 +

+
+
+
+
+
+4. IANA Considerations +
+
+
+
+4. IANAの考慮事項 +
+
+
+
+
+

+This document has no IANA actions. +

+
+
+

+このドキュメントにはIANAアクションがありません。 +

+
+
+
+
+
+5. Security Considerations +
+
+
+
+5. セキュリティに関する考慮事項 +
+
+
+
+
+

+[RFC8283] describes how the security considerations for a PCECC are a little different from those for any other PCE system. PCECC operations rely heavily on the use and security of PCEP, so due consideration should be given to the security features discussed in [RFC5440] and the additional mechanisms described in [RFC8253]. It further lists the vulnerability of a central controller architecture, such as a central point of failure, denial of service, and a focus on interception and modification of messages sent to individual Network Elements (NEs). +

+
+
+

+[RFC8283]は、PCECCのセキュリティ上の考慮事項が他のPCEシステムのセキュリティに関する考慮事項とは少し異なる方法を説明しています。PCECCの操作は、PCEPの使用とセキュリティに大きく依存しているため、[RFC5440]で説明されているセキュリティ機能と[RFC8253]で説明されている追加のメカニズムに十分な考慮を払う必要があります。さらに、障害の中央点、サービス拒否、個々のネットワーク要素（NES）に送信されるメッセージの傍受と変更に焦点を当てるなど、中央コントローラーアーキテクチャの脆弱性をリストします。 +

+
+
+
+
+

+As per [RFC9050], the use of Transport Layer Security (TLS) in PCEP is recommended, as it provides support for peer authentication, message encryption, and integrity. It further provides mechanisms for associating peer identities with different levels of access and/ or authoritativeness via an attribute in X.509 certificates or a local policy with a specific accept-list of X.509 certificates. This can be used to check the authority for the PCECC operations. +

+
+
+

+[RFC9050]によると、PCEPでの輸送層セキュリティ（TLS）の使用が推奨されます。これは、ピア認証、メッセージ暗号化、および完全性をサポートするためです。さらに、X.509証明書の属性またはX.509証明書の特定の受け入れリストを持つ属性を介して、異なるレベルのアクセスおよび/または権威性を持つピアアイデンティティを関連付けるためのメカニズムを提供します。これは、PCECC操作の権限を確認するために使用できます。 +

+
+
+
+
+

+It is expected that each new document that is produced for a specific use case will also include considerations of the security impacts of the use of a PCECC on the network type and services being managed. +

+
+
+

+特定のユースケース用に作成された各新しいドキュメントには、管理対象のネットワークタイプとサービスに対するPCECCの使用のセキュリティへの影響に関する考慮事項も含まれることが期待されています。 +

+
+
+
+
+
+6. References +
+
+
+
+6. 参考文献 +
+
+
+
+
+
+6.1. Normative References +
+
+
+
+6.1. 引用文献 +
+
+
+
+
+ 
+   [RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
+              Element (PCE) Communication Protocol (PCEP)", RFC 5440,
+              DOI 10.17487/RFC5440, March 2009,
+              <https://www.rfc-editor.org/info/rfc5440>.
+
+
+
+
+
+ 
+   [RFC7665]  Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
+              Chaining (SFC) Architecture", RFC 7665,
+              DOI 10.17487/RFC7665, October 2015,
+              <https://www.rfc-editor.org/info/rfc7665>.
+
+
+
+
+
+ 
+   [RFC8231]  Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
+              Computation Element Communication Protocol (PCEP)
+              Extensions for Stateful PCE", RFC 8231,
+              DOI 10.17487/RFC8231, September 2017,
+              <https://www.rfc-editor.org/info/rfc8231>.
+
+
+
+
+
+ 
+   [RFC8253]  Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
+              "PCEPS: Usage of TLS to Provide a Secure Transport for the
+              Path Computation Element Communication Protocol (PCEP)",
+              RFC 8253, DOI 10.17487/RFC8253, October 2017,
+              <https://www.rfc-editor.org/info/rfc8253>.
+
+
+
+
+
+ 
+   [RFC8281]  Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
+              Computation Element Communication Protocol (PCEP)
+              Extensions for PCE-Initiated LSP Setup in a Stateful PCE
+              Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
+              <https://www.rfc-editor.org/info/rfc8281>.
+
+
+
+
+
+ 
+   [RFC8283]  Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An
+              Architecture for Use of PCE and the PCE Communication
+              Protocol (PCEP) in a Network with Central Control",
+              RFC 8283, DOI 10.17487/RFC8283, December 2017,
+              <https://www.rfc-editor.org/info/rfc8283>.
+
+
+
+
+
+ 
+   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
+              Decraene, B., Litkowski, S., and R. Shakir, "Segment
+              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
+              July 2018, <https://www.rfc-editor.org/info/rfc8402>.
+
+
+
+
+
+
+6.2. Informative References +
+
+
+
+6.2. 参考引用 +
+
+
+
+
+ 
+   [MAP-REDUCE]
+              Lee, K., Choi, T., Ganguly, A., Wolinsky, D., Boykin, P.,
+              and R. Figueiredo, "Parallel Processing Framework on a P2P
+              System Using Map and Reduce Primitives",
+              DOI 10.1109/IPDPS.2011.315, May 2011,
+              <https://leeky.me/publications/mapreduce_p2p.pdf>.
+
+
+
+
+
+ 
+   [MPLS-DC]  Afanasiev, D. and D. Ginsburg, "MPLS in DC and inter-DC
+              networks: the unified forwarding mechanism for network
+              programmability at scale", March 2014,
+              <https://www.slideshare.net/DmitryAfanasiev1/yandex-
+              nag201320131031>.
+
+
+
+
+
+ 
+   [MPLS-SEAMLESS]
+              Leymann, N., Ed., Decraene, B., Filsfils, C.,
+              Konstantynowicz, M., Ed., and D. Steinberg, "Seamless MPLS
+              Architecture", Work in Progress, Internet-Draft, draft-
+              ietf-mpls-seamless-mpls-07, 28 June 2014,
+              <https://datatracker.ietf.org/doc/html/draft-ietf-mpls-
+              seamless-mpls-07>.
+
+
+
+
+
+ 
+   [PCE-ID]   Li, C., Shi, H., Ed., Wang, A., Cheng, W., and C. Zhou,
+              "Path Computation Element Communication Protocol (PCEP)
+              extension to advertise the PCE Controlled Identifier
+              Space", Work in Progress, Internet-Draft, draft-ietf-pce-
+              controlled-id-space-01, 21 October 2024,
+              <https://datatracker.ietf.org/doc/html/draft-ietf-pce-
+              controlled-id-space-01>.
+
+
+
+
+
+ 
+   [PCE-INTERDOMAIN]
+              Dugeon, O., Meuric, J., Lee, Y., and D. Ceccarelli, "PCEP
+              Extension for Stateful Inter-Domain Tunnels", Work in
+              Progress, Internet-Draft, draft-ietf-pce-stateful-
+              interdomain-05, 5 July 2024,
+              <https://datatracker.ietf.org/doc/html/draft-ietf-pce-
+              stateful-interdomain-05>.
+
+
+
+
+
+ 
+   [PCE-PROTECTION]
+              Barth, C. and R. Torvi, "PCEP Extensions for RSVP-TE
+              Local-Protection with PCE-Stateful", Work in Progress,
+              Internet-Draft, draft-cbrt-pce-stateful-local-protection-
+              01, 29 June 2018, <https://datatracker.ietf.org/doc/html/
+              draft-cbrt-pce-stateful-local-protection-01>.
+
+
+
+
+
+ 
+   [PCECC-BIER]
+              Chen, R., Zhu, C., Xu, B., Chen, H., and A. Wang, "PCEP
+              Procedures and Protocol Extensions for Using PCE as a
+              Central Controller (PCECC) of BIER", Work in Progress,
+              Internet-Draft, draft-chen-pce-pcep-extension-pce-
+              controller-bier-06, 8 July 2024,
+              <https://datatracker.ietf.org/doc/html/draft-chen-pce-
+              pcep-extension-pce-controller-bier-06>.
+
+
+
+
+
+ 
+   [PCECC-SR] Li, Z., Peng, S., Negi, M. S., Zhao, Q., and C. Zhou, "PCE
+              Communication Protocol (PCEP) Extensions for Using PCE as
+              a Central Controller (PCECC) for Segment Routing (SR) MPLS
+              Segment Identifier (SID) Allocation and Distribution.",
+              Work in Progress, Internet-Draft, draft-ietf-pce-pcep-
+              extension-pce-controller-sr-09, 4 July 2024,
+              <https://datatracker.ietf.org/doc/html/draft-ietf-pce-
+              pcep-extension-pce-controller-sr-09>.
+
+
+
+
+
+ 
+   [PCECC-SRv6]
+              Li, Z., Peng, S., Geng, X., and M. S. Negi, "PCE
+              Communication Protocol (PCEP) Extensions for Using the PCE
+              as a Central Controller (PCECC) for Segment Routing over
+              IPv6 (SRv6) Segment Identifier (SID) Allocation and
+              Distribution.", Work in Progress, Internet-Draft, draft-
+              ietf-pce-pcep-extension-pce-controller-srv6-03, 18 August
+              2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
+              pce-pcep-extension-pce-controller-srv6-03>.
+
+
+
+
+
+ 
+   [PCEP-BIER]
+              Chen, R., Zhang, Z., Chen, H., Dhanaraj, S., Qin, F., and
+              A. Wang, "PCEP Extensions for Tree Engineering for Bit
+              Index Explicit Replication (BIER-TE)", Work in Progress,
+              Internet-Draft, draft-ietf-pce-bier-te-01, 10 October
+              2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
+              pce-bier-te-01>.
+
+
+
+
+
+ 
+   [PCEP-NATIVE]
+              Wang, A., Khasanov, B., Fang, S., Tan, R., and C. Zhu,
+              "Path Computation Element Communication Protocol (PCEP)
+              Extensions for Native IP Networks", Work in Progress,
+              Internet-Draft, draft-ietf-pce-pcep-extension-native-ip-
+              40, 10 September 2024,
+              <https://datatracker.ietf.org/doc/html/draft-ietf-pce-
+              pcep-extension-native-ip-40>.
+
+
+
+
+
+ 
+   [PCEP-POLICY]
+              Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H.
+              Bidgoli, "Path Computation Element Communication Protocol
+              (PCEP) Extensions for Segment Routing (SR) Policy
+              Candidate Paths", Work in Progress, Internet-Draft, draft-
+              ietf-pce-segment-routing-policy-cp-18, 14 October 2024,
+              <https://datatracker.ietf.org/doc/html/draft-ietf-pce-
+              segment-routing-policy-cp-18>.
+
+
+
+
+
+ 
+   [RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
+              dual environments", RFC 1195, DOI 10.17487/RFC1195,
+              December 1990, <https://www.rfc-editor.org/info/rfc1195>.
+
+
+
+
+
+ 
+   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328,
+              DOI 10.17487/RFC2328, April 1998,
+              <https://www.rfc-editor.org/info/rfc2328>.
+
+
+
+
+
+ 
+   [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
+              and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
+              Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
+              <https://www.rfc-editor.org/info/rfc3209>.
+
+
+
+
+
+ 
+   [RFC3985]  Bryant, S., Ed. and P. Pate, Ed., "Pseudo Wire Emulation
+              Edge-to-Edge (PWE3) Architecture", RFC 3985,
+              DOI 10.17487/RFC3985, March 2005,
+              <https://www.rfc-editor.org/info/rfc3985>.
+
+
+
+
+
+ 
+   [RFC4206]  Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
+              Hierarchy with Generalized Multi-Protocol Label Switching
+              (GMPLS) Traffic Engineering (TE)", RFC 4206,
+              DOI 10.17487/RFC4206, October 2005,
+              <https://www.rfc-editor.org/info/rfc4206>.
+
+
+
+
+
+ 
+   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
+              Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
+              2006, <https://www.rfc-editor.org/info/rfc4364>.
+
+
+
+
+
+ 
+   [RFC4456]  Bates, T., Chen, E., and R. Chandra, "BGP Route
+              Reflection: An Alternative to Full Mesh Internal BGP
+              (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
+              <https://www.rfc-editor.org/info/rfc4456>.
+
+
+
+
+
+ 
+   [RFC4655]  Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
+              Computation Element (PCE)-Based Architecture", RFC 4655,
+              DOI 10.17487/RFC4655, August 2006,
+              <https://www.rfc-editor.org/info/rfc4655>.
+
+
+
+
+
+ 
+   [RFC5036]  Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
+              "LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
+              October 2007, <https://www.rfc-editor.org/info/rfc5036>.
+
+
+
+
+
+ 
+   [RFC5150]  Ayyangar, A., Kompella, K., Vasseur, JP., and A. Farrel,
+              "Label Switched Path Stitching with Generalized
+              Multiprotocol Label Switching Traffic Engineering (GMPLS
+              TE)", RFC 5150, DOI 10.17487/RFC5150, February 2008,
+              <https://www.rfc-editor.org/info/rfc5150>.
+
+
+
+
+
+ 
+   [RFC5151]  Farrel, A., Ed., Ayyangar, A., and JP. Vasseur, "Inter-
+              Domain MPLS and GMPLS Traffic Engineering -- Resource
+              Reservation Protocol-Traffic Engineering (RSVP-TE)
+              Extensions", RFC 5151, DOI 10.17487/RFC5151, February
+              2008, <https://www.rfc-editor.org/info/rfc5151>.
+
+
+
+
+
+ 
+   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
+              for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
+              <https://www.rfc-editor.org/info/rfc5340>.
+
+
+
+
+
+ 
+   [RFC5376]  Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS
+              Requirements for the Path Computation Element
+              Communication Protocol (PCECP)", RFC 5376,
+              DOI 10.17487/RFC5376, November 2008,
+              <https://www.rfc-editor.org/info/rfc5376>.
+
+
+
+
+
+ 
+   [RFC5541]  Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
+              Objective Functions in the Path Computation Element
+              Communication Protocol (PCEP)", RFC 5541,
+              DOI 10.17487/RFC5541, June 2009,
+              <https://www.rfc-editor.org/info/rfc5541>.
+
+
+
+
+
+ 
+   [RFC7025]  Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C.
+              Margaria, "Requirements for GMPLS Applications of PCE",
+              RFC 7025, DOI 10.17487/RFC7025, September 2013,
+              <https://www.rfc-editor.org/info/rfc7025>.
+
+
+
+
+
+ 
+   [RFC7399]  Farrel, A. and D. King, "Unanswered Questions in the Path
+              Computation Element Architecture", RFC 7399,
+              DOI 10.17487/RFC7399, October 2014,
+              <https://www.rfc-editor.org/info/rfc7399>.
+
+
+
+
+
+ 
+   [RFC7432]  Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
+              Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
+              Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
+              2015, <https://www.rfc-editor.org/info/rfc7432>.
+
+
+
+
+
+ 
+   [RFC7491]  King, D. and A. Farrel, "A PCE-Based Architecture for
+              Application-Based Network Operations", RFC 7491,
+              DOI 10.17487/RFC7491, March 2015,
+              <https://www.rfc-editor.org/info/rfc7491>.
+
+
+
+
+
+ 
+   [RFC8279]  Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
+              Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
+              Explicit Replication (BIER)", RFC 8279,
+              DOI 10.17487/RFC8279, November 2017,
+              <https://www.rfc-editor.org/info/rfc8279>.
+
+
+
+
+
+ 
+   [RFC8300]  Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed.,
+              "Network Service Header (NSH)", RFC 8300,
+              DOI 10.17487/RFC8300, January 2018,
+              <https://www.rfc-editor.org/info/rfc8300>.
+
+
+
+
+
+ 
+   [RFC8355]  Filsfils, C., Ed., Previdi, S., Ed., Decraene, B., and R.
+              Shakir, "Resiliency Use Cases in Source Packet Routing in
+              Networking (SPRING) Networks", RFC 8355,
+              DOI 10.17487/RFC8355, March 2018,
+              <https://www.rfc-editor.org/info/rfc8355>.
+
+
+
+
+
+ 
+   [RFC8408]  Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J.
+              Hardwick, "Conveying Path Setup Type in PCE Communication
+              Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408,
+              July 2018, <https://www.rfc-editor.org/info/rfc8408>.
+
+
+
+
+
+ 
+   [RFC8664]  Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
+              and J. Hardwick, "Path Computation Element Communication
+              Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
+              DOI 10.17487/RFC8664, December 2019,
+              <https://www.rfc-editor.org/info/rfc8664>.
+
+
+
+
+
+ 
+   [RFC8735]  Wang, A., Huang, X., Kou, C., Li, Z., and P. Mi,
+              "Scenarios and Simulation Results of PCE in a Native IP
+              Network", RFC 8735, DOI 10.17487/RFC8735, February 2020,
+              <https://www.rfc-editor.org/info/rfc8735>.
+
+
+
+
+
+ 
+   [RFC8751]  Dhody, D., Lee, Y., Ceccarelli, D., Shin, J., and D. King,
+              "Hierarchical Stateful Path Computation Element (PCE)",
+              RFC 8751, DOI 10.17487/RFC8751, March 2020,
+              <https://www.rfc-editor.org/info/rfc8751>.
+
+
+
+
+
+ 
+   [RFC8754]  Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
+              Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
+              (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
+              <https://www.rfc-editor.org/info/rfc8754>.
+
+
+
+
+
+ 
+   [RFC8821]  Wang, A., Khasanov, B., Zhao, Q., and H. Chen, "PCE-Based
+              Traffic Engineering (TE) in Native IP Networks", RFC 8821,
+              DOI 10.17487/RFC8821, April 2021,
+              <https://www.rfc-editor.org/info/rfc8821>.
+
+
+
+
+
+ 
+   [RFC8955]  Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M.
+              Bacher, "Dissemination of Flow Specification Rules",
+              RFC 8955, DOI 10.17487/RFC8955, December 2020,
+              <https://www.rfc-editor.org/info/rfc8955>.
+
+
+
+
+
+ 
+   [RFC8986]  Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
+              D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
+              (SRv6) Network Programming", RFC 8986,
+              DOI 10.17487/RFC8986, February 2021,
+              <https://www.rfc-editor.org/info/rfc8986>.
+
+
+
+
+
+ 
+   [RFC9012]  Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,
+              "The BGP Tunnel Encapsulation Attribute", RFC 9012,
+              DOI 10.17487/RFC9012, April 2021,
+              <https://www.rfc-editor.org/info/rfc9012>.
+
+
+
+
+
+ 
+   [RFC9050]  Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "Path
+              Computation Element Communication Protocol (PCEP)
+              Procedures and Extensions for Using the PCE as a Central
+              Controller (PCECC) of LSPs", RFC 9050,
+              DOI 10.17487/RFC9050, July 2021,
+              <https://www.rfc-editor.org/info/rfc9050>.
+
+
+
+
+
+ 
+   [RFC9087]  Filsfils, C., Ed., Previdi, S., Dawra, G., Ed., Aries, E.,
+              and D. Afanasiev, "Segment Routing Centralized BGP Egress
+              Peer Engineering", RFC 9087, DOI 10.17487/RFC9087, August
+              2021, <https://www.rfc-editor.org/info/rfc9087>.
+
+
+
+
+
+ 
+   [RFC9168]  Dhody, D., Farrel, A., and Z. Li, "Path Computation
+              Element Communication Protocol (PCEP) Extension for Flow
+              Specification", RFC 9168, DOI 10.17487/RFC9168, January
+              2022, <https://www.rfc-editor.org/info/rfc9168>.
+
+
+
+
+
+ 
+   [RFC9256]  Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
+              A., and P. Mattes, "Segment Routing Policy Architecture",
+              RFC 9256, DOI 10.17487/RFC9256, July 2022,
+              <https://www.rfc-editor.org/info/rfc9256>.
+
+
+
+
+
+ 
+   [RFC9262]  Eckert, T., Ed., Menth, M., and G. Cauchie, "Tree
+              Engineering for Bit Index Explicit Replication (BIER-TE)",
+              RFC 9262, DOI 10.17487/RFC9262, October 2022,
+              <https://www.rfc-editor.org/info/rfc9262>.
+
+
+
+
+
+ 
+   [RFC9491]  Guichard, J., Ed. and J. Tantsura, Ed., "Integration of
+              the Network Service Header (NSH) and Segment Routing for
+              Service Function Chaining (SFC)", RFC 9491,
+              DOI 10.17487/RFC9491, November 2023,
+              <https://www.rfc-editor.org/info/rfc9491>.
+
+
+
+
+
+ 
+   [RFC9522]  Farrel, A., Ed., "Overview and Principles of Internet
+              Traffic Engineering", RFC 9522, DOI 10.17487/RFC9522,
+              January 2024, <https://www.rfc-editor.org/info/rfc9522>.
+
+
+
+
+
+ 
+   [RFC9552]  Talaulikar, K., Ed., "Distribution of Link-State and
+              Traffic Engineering Information Using BGP", RFC 9552,
+              DOI 10.17487/RFC9552, December 2023,
+              <https://www.rfc-editor.org/info/rfc9552>.
+
+
+
+
+
+ 
+   [RFC9603]  Li, C., Ed., Kaladharan, P., Sivabalan, S., Koldychev, M.,
+              and Y. Zhu, "Path Computation Element Communication
+              Protocol (PCEP) Extensions for IPv6 Segment Routing",
+              RFC 9603, DOI 10.17487/RFC9603, July 2024,
+              <https://www.rfc-editor.org/info/rfc9603>.
+
+
+
+
+
+ 
+   [RFC9604]  Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S.,
+              and C. Li, Ed., "Carrying Binding Label/SID in PCE-Based
+              Networks", RFC 9604, DOI 10.17487/RFC9604, August 2024,
+              <https://www.rfc-editor.org/info/rfc9604>.
+
+
+
+
+
+ 
+   [SR-SERVICE]
+              Clad, F., Ed., Xu, X., Ed., Filsfils, C., Bernier, D., Li,
+              C., Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W.,
+              and S. Salsano, "Service Programming with Segment
+              Routing", Work in Progress, Internet-Draft, draft-ietf-
+              spring-sr-service-programming-10, 23 August 2024,
+              <https://datatracker.ietf.org/doc/html/draft-ietf-spring-
+              sr-service-programming-10>.
+
+
+
+
+
+
+Appendix A. Other Use Cases of the PCECC +
+
+
+
+付録A. PCECCのその他のユースケース +
+
+
+
+
+

+This section lists some more use cases of the PCECC that were proposed by operators and discussed within the working group but are not in active development at the time of publication. They are listed here for future consideration. +

+
+
+

+このセクションでは、オペレーターによって提案され、ワーキンググループ内で議論されたが、出版時には積極的な開発にはないPCECCのいくつかの使用ケースをリストします。将来の検討のためにここにリストされています。 +

+
+
+
+
+
+A.1. PCECC for Network Migration +
+
+
+
+A.1. ネットワーク移行のためのPCECC +
+
+
+
+
+

+One of the main advantages of the PCECC solution is its backward compatibility. The PCE server can function as a proxy node of the MPLS network for all the new nodes that no longer support the signalling protocols. +

+
+
+

+PCECCソリューションの主な利点の1つは、後方互換性です。PCEサーバーは、シグナリングプロトコルをサポートしなくなったすべての新しいノードのMPLSネットワークのプロキシノードとして機能することができます。 +

+
+
+
+
+

+As illustrated in the following example, the current network could migrate to a total PCECC-controlled network gradually by replacing the legacy nodes. During the migration, the legacy nodes still need to use the existing MPLS signalling protocols such as LDP and RSVP-TE, and the new nodes will set up their portion of the forwarding path through the PCECC directly. With the PCECC function as the proxy of these new nodes, MPLS signalling can populate through the network for both old and new nodes. +

+
+
+

+次の例に示されているように、現在のネットワークは、レガシーノードを置き換えることにより、PCECC制御ネットワーク全体に徐々に移行する可能性があります。移行中、レガシーノードは依然としてLDPやRSVP-TEなどの既存のMPLSシグナリングプロトコルを使用する必要があり、新しいノードはPCECCを介して転送パスの部分を直接設定します。これらの新しいノードのプロキシとしてPCECC機能を使用すると、MPLSシグナル伝達は、古いノードと新しいノードの両方でネットワークを介して入力できます。 +

+
+
+
+
+

+The example described in this section is based on network configurations illustrated in Figure 13: +

+
+
+

+このセクションで説明する例は、図13に示すネットワーク構成に基づいています。 +

+
+
+
+
+ 
+   +------------------------------------------------------------------+
+   |                         PCE DOMAIN                               |
+   |    +-----------------------------------------------------+       |
+   |    |                       PCECC                         |       |
+   |    +-----------------------------------------------------+       |
+   |     ^              ^                      ^            ^         |
+   |     |      PCEP    |                      |   PCEP     |         |
+   |     V              V                      V            V         |
+   | +--------+   +--------+   +--------+   +--------+   +--------+   |
+   | | Node1  |   | Node2  |   | Node3  |   | Node4  |   | Node5  |   |
+   | |        |...|        |...|        |...|        |...|        |   |
+   | | Legacy |if1| Legacy |if2|Legacy  |if3| PCECC  |if4| PCECC  |   |
+   | |  Node  |   |  Node  |   |Enabled |   |Enabled |   | Enabled|   |
+   | +--------+   +--------+   +--------+   +--------+   +--------+   |
+   |                                                                  |
+   +------------------------------------------------------------------+
+
+
+
+
+
+

+Figure 13: PCECC-Initiated LSP Setup in the Network Migration +

+
+
+

+図13：ネットワーク移行におけるPCECCによって開始されたLSPセットアップ +

+
+
+
+
+

+In this example, there are five nodes for the TE LSP from the headend (Node1) to the tail end (Node5), where Node4 and Node5 are centrally controlled and other nodes are legacy nodes. +

+
+
+

+この例では、ヘッドエンド（node1）からテールエンド（node5）までのte lspの5つのノードがあり、node4とnode5は中心に制御され、他のノードはレガシーノードです。 +

+
+
+
+
+

+* Node1 sends a path request message for the setup of the LSP with the destination as Node5. +

+
+
+

+* node1は、LSPのセットアップのパス要求メッセージをNode5として宛先とともに送信します。 +

+
+
+
+
+

+* The PCECC sends a reply message to Node1 for LSP setup with the path: (Node1, if1), (Node2, if2), (Node3, if3), (Node4, if4), Node5. +

+
+
+

+* PCECCは、パス：（node1、if1）、（node2、if2）、（node3、if3）、（node4、if4）、node5を使用して、lspセットアップに対してnode1に返信メッセージを送信します。 +

+
+
+
+
+

+* Node1, Node2, and Node3 will set up the LSP to Node5 using the local labels as usual. With the help of the PCECC, Node3 could proxy the signalling. +

+
+
+

+* node1、node2、およびnode3は、通常どおりローカルラベルを使用してLSPをnode5に設定します。PCECCの助けを借りて、node3はシグナリングをプロキシできます。 +

+
+
+
+
+

+* Then, the PCECC will program the out-segment of Node3, the in-segment/out-segment of Node4, and the in-segment for Node5. +

+
+
+

+* 次に、PCECCは、node3のアウトセグメント、node4のインセグメント/アウトセグメント、およびnode5のセグメントをプログラムします。 +

+
+
+
+
+
+A.2. PCECC for L3VPN and PWE3 +
+
+
+
+A.2. L3VPNおよびPWE3のPCECC +
+
+
+
+
+

+As described in [RFC8283], various network services may be offered over a network. These include protection services (including Virtual Private Network (VPN) services such as L3VPN [RFC4364] or EVPNs [RFC7432]) or pseudowires [RFC3985]. Delivering services over a network in an optimal way requires coordination in the way where network resources are allocated to support the services. A PCECC can consider the whole network and all components of a service at once when planning how to deliver the service. It can then use PCEP to manage the network resources and to install the necessary associations between those resources. +

+
+
+

+[RFC8283]で説明されているように、さまざまなネットワークサービスがネットワークを介して提供される場合があります。これらには、保護サービス（L3VPN [RFC4364]やEVPNS [RFC7432]などの仮想プライベートネットワーク（VPN）サービスを含む）またはプソイドワイヤ[RFC3985]が含まれます。ネットワーク上でサービスを最適な方法で提供するには、サービスをサポートするためにネットワークリソースが割り当てられる方法で調整が必要です。PCECCは、サービスの提供方法を計画する際に、ネットワーク全体とサービスのすべてのコンポーネントを一度に考慮することができます。その後、PCEPを使用してネットワークリソースを管理し、それらのリソース間に必要な関連付けをインストールできます。 +

+
+
+
+
+

+In the case of L3VPN, VPN labels could also be assigned and distributed through PCEP among the Provider Edge (PE) router instead of using the BGP protocols. +

+
+
+

+L3VPNの場合、VPNラベルは、BGPプロトコルを使用する代わりに、プロバイダーエッジ（PE）ルーターの間でPCEPを介して割り当てて分布することもできます。 +

+
+
+
+
+

+The example described in this section is based on network configurations illustrated in Figure 14: +

+
+
+

+このセクションで説明する例は、図14に示すネットワーク構成に基づいています。 +

+
+
+
+
+ 
+               +-------------------------------------------+
+               |                   PCE DOMAIN              |
+               |    +-----------------------------------+  |
+               |    |                PCECC              |  |
+               |    +-----------------------------------+  |
+               |           ^          ^              ^     |
+               | PWE3/L3VPN|PCEP  PCEP|LSP PWE3/L3VPN|PCEP |
+               |           V          V              V     |
+    +--------+ |     +--------+   +--------+   +--------+  |  +--------+
+    |  CE    | |     | PE1    |   | Node x |   | PE2    |  |  |   CE   |
+    |        |...... |        |...|        |...|        |.....|        |
+    | Legacy | |if1  | PCECC  |if2|PCECC   |if3| PCECC  |if4  | Legacy |
+    |  Node  | |     | Enabled|   |Enabled |   |Enabled |  |  |  Node  |
+    +--------+ |     +--------+   +--------+   +--------+  |  +--------+
+               |                                           |
+               +-------------------------------------------+
+
+
+
+
+
+

+Figure 14: PCECC for L3VPN and PWE3 +

+
+
+

+図14：L3VPNおよびPWE3のPCECC +

+
+
+
+
+

+In the case of PWE3, instead of using the LDP signalling protocols, the label and port pairs assigned to each pseudowire can be assigned through the PCECC among the PE routers and the corresponding forwarding entries will be distributed into each PE router through the extended PCEP and PCECC mechanism. +

+
+
+

+PWE3の場合、LDPシグナル伝達プロトコルを使用する代わりに、各擬似ワイヤに割り当てられたラベルとポートペアは、PEルーターの間でPCECCを介して割り当てることができ、対応する転送エントリは拡張されたPCEPを介して各PEルーターに配布されます。PCECCメカニズム。 +

+
+
+
+
+
+A.3. PCECC for Local Protection (RSVP-TE) +
+
+
+
+A.3. ローカル保護のためのPCECC（RSVP-TE） +
+
+
+
+
+

+[PCE-PROTECTION] claims that there is a need for the PCE to maintain and associate the local protection paths for the RSVP-TE LSP. Local protection requires the setup of a bypass at the PLR. This bypass can be PCC-initiated and delegated or PCE-initiated. In either case, the PLR needs to maintain a PCEP session with the PCE. The bypass LSPs need to be mapped to the primary LSP. This could be done locally at the PLR based on a local policy, but there is a need for a PCE to do the mapping as well to exert greater control. +

+
+
+

+[PCE保護]は、PCEがRSVP-TE LSPのローカル保護パスを維持および関連付ける必要があると主張しています。ローカル保護には、PLRでのバイパスのセットアップが必要です。このバイパスは、PCC開始および委任またはPCE開始を行うことができます。どちらの場合でも、PLRはPCEとのPCEPセッションを維持する必要があります。バイパスLSPをプライマリLSPにマッピングする必要があります。これは、ローカルポリシーに基づいてPLRでローカルに行うことができますが、PCEがマッピングを行う必要があります。 +

+
+
+
+
+

+This mapping can be done via PCECC procedures where the PCE could instruct the PLR to the mapping and identify the primary LSP for which bypass should be used. +

+
+
+

+このマッピングは、PCEがPLRにマッピングを指示し、バイパスを使用する主要なLSPを識別できるPCECC手順を介して実行できます。 +

+
+
+
+
+
+A.4. Using Reliable P2MP TE-Based Multicast Delivery for Distributed Computations (MapReduce-Hadoop) +
+
+
+
+A.4. 分散計算に信頼性の高いP2MP TEベースのマルチキャスト配信を使用（MapReduce-Hadoop） +
+
+
+
+
+

+The MapReduce model of distributed computations in computing clusters is widely deployed. In Hadoop (https://hadoop.apache.org/) 1.0 architecture, MapReduce operations occur on big data in the Hadoop Distributed File System (HDFS), where NameNode knows about resources of the cluster and where actual data (chunks) for a particular task are located (which DataNode). Each chunk of data (64 MB or more) should have three saved copies in different DataNodes based on their proximity. +

+
+
+

+コンピューティングクラスターの分散計算のMapReduceモデルは広く展開されています。Hadoop（https://hadoop.apache.org/）1.0アーキテクチャでは、MapReduce操作はHadoop分散ファイルシステム（HDFS）のビッグデータで発生します。特定のタスクが配置されています（このデータノード）。データの各チャンク（64 MB以上）には、近接に基づいて異なるデータノードに3つの保存されたコピーが必要です。 +

+
+
+
+
+

+The proximity level currently has a semi-manual allocation and is based on Rack IDs (the assumption is that closer data is better because of access speed / smaller latency). +

+
+
+

+近接レベルには現在、セミマニュアル割り当てがあり、ラックIDに基づいています（アクセス速度 /レイテンシーが小さいため、より近いデータが優れていると仮定しています）。 +

+
+
+
+
+

+The JobTracker node is responsible for computation tasks and scheduling across DataNodes and also has Rack awareness. Currently, transport protocols between NameNode/JobTracker and DataNodes are based on IP unicast. It has simplicity as an advantage but has numerous drawbacks related to its flat approach. +

+
+
+

+JobTrackerノードは、DataNodes全体の計算タスクとスケジューリングを担当し、ラック認識もあります。現在、NameNode/JobTrackerとDatanodesの間の輸送プロトコルは、IPユニキャストに基づいています。それは利点としてシンプルさを持っていますが、そのフラットなアプローチに関連する多くの欠点があります。 +

+
+
+
+
+

+There is a need to go beyond one data center (DC) for Hadoop cluster creation and move towards distributed clusters. In that case, one needs to handle performance and latency issues. Latency depends on the speed of light in the fiber links and on the latency introduced by intermediate devices in between. The latter is closely correlated with network device architecture and performance. The current performance of routers based on Network Processing Unit (NPU) should be enough for creating distributed Hadoop clusters with predicted latency. The performance of software-based routers (mainly Virtual Network Functions (VNFs)) with additional hardware features such as the Data Plane Development Kit (DPDK) is promising but requires additional research and testing. +

+
+
+

+Hadoopクラスターの作成には、1つのデータセンター（DC）を超えて、分散クラスターに向かって移動する必要があります。その場合、パフォーマンスとレイテンシの問題を処理する必要があります。遅延は、ファイバーリンクの光の速度と、その間の中間デバイスによって導入されたレイテンシに依存します。後者は、ネットワークデバイスのアーキテクチャとパフォーマンスと密接に相関しています。ネットワーク処理ユニット（NPU）に基づくルーターの現在のパフォーマンスは、予測された遅延を備えた分散Hadoopクラスターを作成するのに十分でなければなりません。データプレーン開発キット（DPDK）などの追加のハードウェア機能を備えたソフトウェアベースのルーター（主に仮想ネットワーク関数（VNFS））のパフォーマンスは有望ですが、追加の研究とテストが必要です。 +

+
+
+
+
+

+The main question is how to create a simple but effective architecture for a distributed Hadoop cluster. +

+
+
+

+主な問題は、分散型Hadoopクラスターのシンプルだが効果的なアーキテクチャをどのように作成するかです。 +

+
+
+
+
+

+There is research [MAP-REDUCE] that shows how usage of the multicast tree could improve the speed of resource or cluster members' discovery inside the cluster as well as increased redundancy in communications between cluster nodes. +

+
+
+

+マルチキャストツリーの使用がクラスター内のリソースまたはクラスターメンバーの発見の速度をどのように改善し、クラスターノード間の通信の冗長性を高めることができるかを示す研究[Map-Reduce]があります。 +

+
+
+
+
+

+The conventional IP-based multicast may not be appropriate because it requires an additional control plane (IGMP, PIM) and a lot of signalling, which is not suitable for high-performance computations that are very sensitive to latency. +

+
+
+

+従来のIPベースのマルチキャストは、追加のコントロールプレーン（IGMP、PIM）と多くのシグナル伝達が必要であるため、適切ではない場合があります。 +

+
+
+
+
+

+P2MP TE tunnels are more suitable as a potential solution for the creation of multicast-based communications between NameNode as the root and DataNodes as leaves inside the cluster. These P2MP tunnels could be dynamically created and turned down (with no manual intervention). Here, the PCECC comes into play with the main objective of creating an optimal topology for each particular request for MapReduce computation and creating P2MP tunnels with needed parameters such as BW and delay. +

+
+
+

+P2MP TEトンネルは、クラスター内の葉としてのルートとしてのナメノーデとデータノードの間のマルチキャストベースの通信を作成するための潜在的なソリューションとしてより適しています。これらのP2MPトンネルは、動的に作成されて倒すことができます（手動介入なし）。ここで、PCECCは、MapReduce計算の特定の要求に対して最適なトポロジを作成し、BWや遅延などの必要なパラメーターを備えたP2MPトンネルを作成するという主な目的で作用します。 +

+
+
+
+
+

+This solution will require the use of MPLS label-based forwarding inside the cluster. The usage of label-based forwarding inside DC was proposed by Yandex [MPLS-DC]. Technically, it is already possible because MPLS on switches is already supported by some vendors, and MPLS also exists on Linux and Open vSwitch (OVS). +

+
+
+

+このソリューションでは、クラスター内のMPLSラベルベースの転送を使用する必要があります。DC内のラベルベースの転送の使用は、Yandex [MPLS-DC]によって提案されました。技術的には、スイッチ上のMPLSは一部のベンダーによってすでにサポートされており、MPLSはLinuxおよびOpen Vswitch（OVS）にも存在するため、すでに可能です。 +

+
+
+
+
+

+A possible framework for this task is shown in Figure 15: +

+
+
+

+このタスクの可能なフレームワークを図15に示します。 +

+
+
+
+
+ 
+                      +--------+
+                      |  APP   |
+                      +--------+
+                           | NBI (REST API,...)
+                           |
+               PCEP       +----------+  REST API
+        +---------+   +---|  PCECC   |----------+
+        | Client  |---|---|          |          |
+        +---------+   |   +----------+          |
+                |     |       | |  |            |
+                +-----|---+   |PCEP|            |
+             +--------+   |   | |  |            |
+             |            |   | |  |            |
+             | REST API   |   | |  |            |
+             |            |   | |  |            |
+   +-------------+        |   | |  |           +----------+
+   | Job Tracker |        |   | |  |           | NameNode |
+   |             |        |   | |  |           |          |
+   +-------------+        |   | |  |           +----------+
+           +------------------+ |  +-----------+
+           |              |     |              |
+       |---+-----P2MP TE--+-----|-----------|  |
+   +-----------+       +-----------+      +-----------+
+   | DataNode1 |       | DataNode2 |      | DataNodeN |
+   |TaskTracker|       |TaskTracker| .... |TaskTracker|
+   +-----------+       +-----------+      +-----------+
+
+
+
+
+
+

+Figure 15: Using Reliable P2MP TE-Based Multicast Delivery for Distributed Computations (MapReduce-Hadoop) +

+
+
+

+図15：分散計算に信頼できるP2MP TEベースのマルチキャスト配信の使用（MapReduce-Hadoop） +

+
+
+
+
+

+Communication between the JobTracker, NameNode, and PCECC can be done via REST API directly or via a cluster manager such as Mesos. +

+
+
+

+JobTracker、Namenode、およびPCECC間の通信は、REST APIを直接またはMESOなどのクラスターマネージャーを介して実行できます。 +

+
+
+
+
+

+* Phase 1: Distributed cluster resource discovery occurs during this phase. JobTracker and NameNode should identify and find available DataNodes according to computing requests from the application (APP). NameNode should query the PCECC about available DataNodes, and NameNode may provide additional constraints to the PCECC such as topological proximity and redundancy level. +

+
+
+

+* フェーズ1：分散クラスターリソースの発見は、このフェーズで発生します。JobTrackerとNameNodeは、アプリケーション（APP）からのコンピューティング要求に従って、利用可能なデータノードを識別して見つけて見つける必要があります。NameNodeは、利用可能なデータノードについてPCECCを照会する必要があり、NameNodeはトポロジーの近接性や冗長性レベルなどのPCECCに追加の制約を提供する場合があります。 +

+
+
+
+
+

+The PCECC should analyze the topology of the distributed cluster and perform a constraint-based path calculation from the client towards the most suitable NameNodes. The PCECC should reply to NameNode with the list of the most suitable DataNodes and their resource capabilities. The topology discovery mechanism for the PCECC will be added later to that framework. +

+
+
+

+PCECCは、分散クラスターのトポロジを分析し、クライアントから最も適切なナメノードへの制約ベースのパス計算を実行する必要があります。PCECCは、最も適切なデータノードとそのリソース機能のリストを使用してNamenodeに返信する必要があります。PCECCのトポロジ発見メカニズムは、後でそのフレームワークに追加されます。 +

+
+
+
+
+

+* Phase 2: The PCECC should create P2MP LSPs from the client towards those DataNodes by means of PCEP messages following the previously calculated path. +

+
+
+

+* フェーズ2：PCECCは、以前に計算されたパスに続いてPCEPメッセージを使用して、クライアントからそれらのデータロードに向かってP2MP LSPを作成する必要があります。 +

+
+
+
+
+

+* Phase 3: NameNode should send this information to the client, and the PCECC should inform the client about the optimal P2MP path towards DataNodes via a PCEP message. +

+
+
+

+* フェーズ3：NAMENODEはこの情報をクライアントに送信する必要があり、PCECCはPCEPメッセージを介してDatanodesへの最適なP2MPパスについてクライアントに通知する必要があります。 +

+
+
+
+
+

+* Phase 4: The client sends data blocks to those DataNodes for writing via the created P2MP tunnel. +

+
+
+

+* フェーズ4：クライアントは、作成されたP2MPトンネルを介して書き込むために、これらのデータロードにデータブロックを送信します。 +

+
+
+
+
+

+When this task is finished, the P2MP tunnel could be turned down. +

+
+
+

+このタスクが終了すると、P2MPトンネルを倒すことができます。 +

+
+
+
+
+
+Acknowledgments +
+
+
+
+謝辞 +
+
+
+
+
+

+Thanks to Adrian Farrel, Aijun Wang, Robert Tao, Changjiang Yan, Tieying Huang, Sergio Belotti, Dieter Beller, Andrey Elperin, and Evgeniy Brodskiy for their useful comments and suggestions. +

+
+
+

+エイドリアン・ファレル、アイジュン・ワン、ロバート・タオ、チャンジャン・ヤン、ティーイング・ファン、セルジオ・ベロッティ、ディーター・ベラー、アンドレイ・エルペリン、エヴゲニー・ブロズキーの有用なコメントと提案のおかげで。 +

+
+
+
+
+

+Thanks to Mach Chen and Carlos Pignataro for the RTGDIR review. Thanks to Derrell Piper for the SECDIR review. Thanks to Sue Hares for GENART review. +

+
+
+

+RTGDIRレビューをしてくれたMach ChenとCarlos Pignataroに感謝します。SecdirレビューをしてくれたDerrell Piperに感謝します。GenArt ReviewのSue Haresに感謝します。 +

+
+
+
+
+

+Thanks to Vishnu Pavan Beeram for being the document shepherd and Jim Guichard for being the responsible AD. +

+
+
+

+Vishnu Pavan Bearamが羊飼いであることを担当してくれたJim Guichardに感謝します。 +

+
+
+
+
+

+Thanks to Roman Danyliw for the IESG review comments. +

+
+
+

+IESGレビューのコメントをしてくれたRoman Danyliwに感謝します。 +

+
+
+
+
+
+Contributors +
+
+
+
+貢献者 +
+
+
+
+
+ 
+   Luyuan Fang
+   United States of America
+   Email: luyuanf@gmail.com
+
+
+
+
+
+ 
+   Chao Zhou
+   HPE
+   Email: chaozhou_us@yahoo.com
+
+
+
+
+
+ 
+   Boris Zhang
+   Amazon
+   Email: zhangyud@amazon.com
+
+
+
+
+
+ 
+   Artsiom Rachytski
+   AWS
+   Germany
+   Email: arachyts@gmail.com
+
+
+
+
+
+ 
+   Anton Hulida
+   AWS
+   Australia
+   Email: hulidant@amazon.com
+
+
+
+
+
+
+Authors' Addresses +
+
+
+
+著者のアドレス +
+
+
+
+
+ 
+   Zhenbin (Robin) Li
+   Huawei Technologies
+   Huawei Bld., No.156 Beiqing Rd.
+   Beijing
+   100095
+   China
+   Email: lizhenbin@huawei.com
+
+
+
+
+
+ 
+   Dhruv Dhody
+   Huawei Technologies
+   India
+   Email: dhruv.ietf@gmail.com
+
+
+
+
+
+ 
+   Quintin Zhao
+   Etheric Networks
+   1009 S Claremont St.
+   San Mateo, CA 94402
+   United States of America
+   Email: quintinzhao@gmail.com
+
+
+
+
+
+ 
+   King He
+   Tencent Holdings Ltd.
+   Shenzhen
+   China
+   Email: kinghe@tencent.com
+
+
+
+
+
+ 
+   Boris Khasanov
+   MTS Web Services (MWS)
+   Andropova Ave. 18, building 9
+   Moscow
+   Russian Federation
+   Email: bhassanov@yahoo.com
+
+
+
+
+ + + diff --git a/html/rfc9697.html b/html/rfc9697.html new file mode 100644 index 000000000..5bc289557 --- /dev/null +++ b/html/rfc9697.html @@ -0,0 +1,840 @@ + + + + + + RFC 9697 - Detecting RPKI Repository Delta Protocol (RRDP) Session Desynchronization 日本語訳 + + + + + + + + + + + + +
+
+ + + +
+
+
+ + +
+
+
+ 
+Internet Engineering Task Force (IETF)                       J. Snijders
+Request for Comments: 9697                                        Fastly
+Updates: 8182                                                 T. de Kock
+Category: Standards Track                                       RIPE NCC
+ISSN: 2070-1721                                            December 2024
+
+
+
+
+
+
+Detecting RPKI Repository Delta Protocol (RRDP) Session Desynchronization +
+
+
+
+RPKIリポジトリデルタプロトコル（RRDP）セッションの解体の検出 +
+
+
+
+
+
+Abstract +
+
+
+
+概要 +
+
+
+
+
+

+This document describes an approach for Resource Public Key Infrastructure (RPKI) Relying Parties to detect a particular form of RPKI Repository Delta Protocol (RRDP) session desynchronization and how to recover. This document updates RFC 8182. +

+
+
+

+このドキュメントでは、RPKIリポジトリデルタプロトコル（RRDP）セッションの非同期化と回復方法を検出するために、リソース公開キーインフラストラクチャ（RPKI）に依存するアプローチについて説明します。このドキュメントは、RFC 8182を更新します。 +

+
+
+
+
+
+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/rfc9697. +

+
+
+

+このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9697で取得できます。 +

+
+
+
+
+
+Copyright Notice +
+
+
+
+著作権表示 +
+
+
+
+
+

+Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. +

+
+
+

+著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。 +

+
+
+
+
+

+This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. +

+
+
+

+このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。 +

+
+
+
+
+
+Table of Contents +
+
+
+
+目次 +
+
+
+
+
+ 
+   1.  Introduction
+     1.1.  Requirements Language
+   2.  Immutability of RRDP Files
+   3.  Detection of Desynchronization
+     3.1.  Example
+   4.  Recovery After Desynchronization
+   5.  Changes to RFC 8182
+   6.  Security Considerations
+   7.  IANA Considerations
+   8.  References
+     8.1.  Normative References
+     8.2.  Informative References
+   Acknowledgements
+   Authors' Addresses
+
+
+
+
+
+
+1. Introduction +
+
+
+
+1. はじめに +
+
+
+
+
+

+The Resource Public Key Infrastructure (RPKI) Repository Delta Protocol (RRDP) [RFC8182] is a one-way synchronization protocol for distributing RPKI data in the form of _differences_ (deltas) between sequential repository states. Relying Parties (RPs) apply a contiguous chain of deltas to synchronize their local copy of the repository with the current state of the remote Repository Server. Delta files for any given session_id and serial number are expected to contain an immutable record of the state of the Repository Server at that given point in time, but this is not always the case. +

+
+
+

+リソース公開キーインフラストラクチャ（RPKI）リポジトリDelta Protocol（RRDP）[RFC8182]は、_Differences_（Deltas）の形でRPKIデータを配布するための一元配置同期プロトコルです。依存関係者（RPS）は、デルタの連続したチェーンを適用して、リモートリポジトリサーバーの現在の状態とリポジトリのローカルコピーを同期させます。任意のSESSION_IDおよびシリアル番号のDeltaファイルには、その時点でリポジトリサーバーの状態の不変の記録が含まれることが期待されていますが、これは必ずしもそうではありません。 +

+
+
+
+
+

+This document describes an approach for RPs to detect a form of RRDP session desynchronization where the hash of a delta for a given serial number and session_id have mutated from the previous Update Notification File and how to recover. +

+
+
+

+このドキュメントでは、RPSが特定のシリアル番号のデルタのハッシュが以前の更新通知ファイルから変異し、回復する方法から変異したRRDPセッションの解体の形式を検出するためのアプローチについて説明します。 +

+
+
+
+
+
+1.1. Requirements Language +
+
+
+
+1.1. 要件言語 +
+
+
+
+
+

+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. +

+
+
+

+「必須」、「必要」、「必須」、「shall」、「shall」、「suff」、 "not"、 "becommended"、 "becommented"、 "may"、 "optional「このドキュメントでは、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。 +

+
+
+
+
+
+2. Immutability of RRDP Files +
+
+
+
+2. RRDPファイルの不変性 +
+
+
+
+
+

+Section 3.1 of [RFC8182] describes how discrete publication events such as the addition, modification, or deletion of one or more repository objects _can_ be communicated as immutable files, highlighting advantages for publishers, such as the ability to precalculate files and make use of caching infrastructure. +

+
+
+

+[RFC8182]のセクション3.1は、1つまたは複数のリポジトリオブジェクトの追加、変更、または削除などの個別の出版イベントを、不変のファイルとして伝達する方法を説明し、ファイルを事前に作成し、キャッシュを使用する能力など、出版社の利点を強調しています。インフラストラクチャー。 +

+
+
+
+
+

+Even though the global RPKI is understood to present a loosely consistent view that depends on the cache's timing of updates (see Section 6 of [RFC7115]), different caches having different data for the same RRDP session at the same serial violates the principle of least astonishment. +

+
+
+

+グローバルRPKIは、キャッシュの更新のタイミングに依存するゆるく一貫したビューを提示すると理解されていますが（[RFC7115]、セクション6を参照）、同じシリアルで同じRRDPセッションの異なるデータを持つ異なるキャッシュは、最低の原則に違反します。驚き。 +

+
+
+
+
+

+If an RRDP server over time serves differing data for a given session_id and serial number, distinct RP instances (depending on the moment they connected to the RRDP server) would end up with divergent local repositories. Comparing only the server-provided session_id and latest serial number across distinct RP instances would not bring such divergence to light. +

+
+
+

+RRDPサーバーが時間の経過とともに、特定のsession_idとシリアル番号の異なるデータを提供する場合、個別のRPインスタンス（RRDPサーバーに接続されている瞬間に応じて）は、異なるローカルリポジトリになります。サーバーが提供するSESSION_IDと個別のRPインスタンス間で最新のシリアル番号のみを比較すると、そのような発散が光になりません。 +

+
+
+
+
+

+The RRDP specification [RFC8182] alludes to immutability being a property of RRDP files, but it doesn't make it clear that immutability is an absolute requirement for the RRDP to work well. +

+
+
+

+RRDP仕様[RFC8182]は、RRDPファイルのプロパティであるという不変性を暗示していますが、RRDPがうまく機能するための絶対的な要件であることは明確ではありません。 +

+
+
+
+
+
+3. Detection of Desynchronization +
+
+
+
+3. 非同期の検出 +
+
+
+
+
+

+Relying Parties can implement a mechanism to keep a record of the serial and hash attribute values in delta elements of the previous successful fetch of an Update Notification File. Then, after fetching a new Update Notification File, the Relying Party should compare if the serial and hash values of previously seen serials match those in the newly fetched file. If any differences are detected, this means that the Delta files were unexpectedly mutated, and the RP should proceed to Section 4. +

+
+
+

+頼る当事者は、更新通知ファイルの以前の成功したフェッチのデルタ要素にシリアルとハッシュの属性値の記録を保持するメカニズムを実装できます。次に、新しいアップデート通知ファイルを取得した後、頼るパーティは、以前に見られたシリアルのシリアル値とハッシュ値が新しくフェッチされたファイルのシリアルと一致する場合に比較する必要があります。違いが検出された場合、これはDeltaファイルが予期せず変異し、RPがセクション4に進む必要があることを意味します。 +

+
+
+
+
+
+3.1. Example +
+
+
+
+3.1. 例 +
+
+
+
+
+

+This section contains two versions of an Update Notification File to demonstrate an unexpected mutation. The initial Update Notification File is as follows: +

+
+
+

+このセクションには、予期しない突然変異を示すために、更新通知ファイルの2つのバージョンが含まれています。初期更新通知ファイルは次のとおりです。 +

+
+
+
+
+ 
+<notification xmlns="http://www.ripe.net/rpki/rrdp" version="1"
+session_id="fe528335-db5f-48b2-be7e-bf0992d0b5ec" serial="1774">
+<snapshot uri="https://rrdp.example.net/1774/snapshot.xml"
+hash=
+"4b5f27b099737b8bf288a33796bfe825fb2014a69fd6aa99080380299952f2e2"
+/>
+<delta serial="1774" uri="https://rrdp.example.net/1774/delta.xml"
+hash=
+"effac94afd30bbf1cd6e180e7f445a4d4653cb4c91068fa9e7b669d49b5aaa00"
+/>
+<delta serial="1773" uri="https://rrdp.example.net/1773/delta.xml"
+hash=
+"731169254dd5de0ede94ba6999bda63b0fae9880873a3710e87a71bafb64761a"
+/>
+<delta serial="1772" uri="https://rrdp.example.net/1772/delta.xml"
+hash=
+"d4087585323fd6b7fd899ebf662ef213c469d39f53839fa6241847f4f6ceb939"
+/>
+</notification>
+
+                               Figure 1
+
+
+
+
+
+

+Based on the above Update Notification File, an RP implementation could record the following state: +

+
+
+

+上記の更新通知ファイルに基づいて、RP実装は次の状態を記録できます。 +

+
+
+
+
+ 
+fe528335-db5f-48b2-be7e-bf0992d0b5ec
+1774 effac94afd30bbf1cd6e180e7f445a4d4653cb4c91068fa9e7b669d49b5aaa00
+1773 731169254dd5de0ede94ba6999bda63b0fae9880873a3710e87a71bafb64761a
+1772 d4087585323fd6b7fd899ebf662ef213c469d39f53839fa6241847f4f6ceb939
+
+                               Figure 2
+
+
+
+
+
+

+A new version of the Update Notification File is published as follows: +

+
+
+

+更新通知ファイルの新しいバージョンは、次のように公開されています。 +

+
+
+
+
+ 
+<notification xmlns="http://www.ripe.net/rpki/rrdp" version="1"
+session_id="fe528335-db5f-48b2-be7e-bf0992d0b5ec" serial="1775">
+<snapshot uri="https://rrdp.example.net/1775/snapshot.xml"
+hash=
+"cd430c386deacb04bda55301c2aa49f192b529989b739f412aea01c9a77e5389"
+/>
+<delta serial="1775" uri="https://rrdp.example.net/1775/delta.xml"
+hash=
+"d199376e98a9095dbcf14ccd49208b4223a28a1327669f89566475d94b2b08cc"
+/>
+<delta serial="1774" uri="https://rrdp.example.net/1774/delta.xml"
+hash=
+"10ca28480a584105a059f95df5ca8369142fd7c8069380f84ebe613b8b89f0d3"
+/>
+<delta serial="1773" uri="https://rrdp.example.net/1773/delta.xml"
+hash=
+"731169254dd5de0ede94ba6999bda63b0fae9880873a3710e87a71bafb64761a"
+/>
+</notification>
+
+                               Figure 3
+
+
+
+
+
+

+Using its previously recorded state (see Figure 2), the RP can compare the hash values for serials 1773 and 1774. For serial 1774, compared to the earlier version of the Update Notification File, a different hash value is now listed, meaning an unexpected delta mutation occurred. +

+
+
+

+以前に記録された状態（図2を参照）を使用して、RPは、Serials 1773および1774のハッシュ値を比較できます。シリアル1774については、更新通知ファイルの以前のバージョンと比較して、別のハッシュ値がリストされています。デルタ変異が発生しました。 +

+
+
+
+
+
+4. Recovery After Desynchronization +
+
+
+
+4. 非同期化後の回復 +
+
+
+
+
+

+Following the detection of RRDP session desynchronization, in order to return to a synchronized state, RP implementations SHOULD issue a warning and SHOULD download the latest Snapshot File and process it as described in Section 3.4.3 of [RFC8182]. +

+
+
+

+RRDPセッションの非同期化の検出後、同期状態に戻るために、RP実装は警告を発行し、[RFC8182]のセクション3.4.3で説明されているように最新のスナップショットファイルをダウンロードし、処理する必要があります。 +

+
+
+
+
+

+See Section 6 for an overview of risks associated with desynchronization. +

+
+
+

+非同期化に関連するリスクの概要については、セクション6を参照してください。 +

+
+
+
+
+
+5. Changes to RFC 8182 +
+
+
+
+5. RFC 8182の変更 +
+
+
+
+
+

+The following paragraph is added to Section 3.4.1 of [RFC8182], "Processing the Update Notification File", after the paragraph that ends "The Relying Party MUST then download and process the Snapshot File specified in the downloaded Update Notification File as described in Section 3.4.3." +

+
+
+

+次の段落は[RFC8182]のセクション3.4.1に追加されます。「更新通知ファイルの処理」を終えた後、「依存者はダウンロードして、ダウンロードされた更新通知ファイルで指定されたスナップショットファイルをダウンロードして処理する必要があります。セクション3.4.3。」 +

+
+
+
+
+

+NEW +

+
+
+

+新しい +

+
+
+
+
+

+If the session_id matches the last known session_id, the Relying Party SHOULD compare whether hash values associated with previously seen files for serials match the hash values of the corresponding serials in the newly fetched Update Notification File. If any differences are detected, this means that files were unexpectedly mutated (see [RFC9697]). The Relying Party SHOULD then download and process the Snapshot File specified in the downloaded Update Notification File as described in Section 3.4.3. +

+
+
+

+session_idが最後の既知のsession_idと一致する場合、頼るパーティは、シリアルの以前に見たファイルに関連付けられたハッシュ値を、新しくフェッチした更新通知ファイルの対応するシリアルのハッシュ値と一致するかどうかを比較する必要があります。違いが検出された場合、これはファイルが予期せず変異したことを意味します（[rfc9697]を参照）。次に、依存関係者は、セクション3.4.3で説明されているように、ダウンロードされた更新通知ファイルで指定されたスナップショットファイルをダウンロードして処理する必要があります。 +

+
+
+
+
+
+6. Security Considerations +
+
+
+
+6. セキュリティに関する考慮事項 +
+
+
+
+
+

+Due to the lifetime of RRDP sessions (often measured in months), desynchronization can persist for an extended period if undetected. +

+
+
+

+RRDPセッションの寿命（多くの場合数か月で測定）により、非同期は検出されない場合は長期間持続できます。 +

+
+
+
+
+

+Caches in a desynchronized state pose a risk by emitting a different set of Validated Payloads than they would otherwise emit with a consistent repository copy. Through the interaction of the desynchronization and the _failed fetch_ mechanism described in Section 6.6 of [RFC9286], Relying Parties could spuriously omit Validated Payloads or emit Validated Payloads that the Certification Authority intended to withdraw. As a result, due to the desynchronized state, route decision making processes might consider route announcements intended to be marked valid as "unknown" or "invalid" for an indeterminate period. +

+
+
+

+非同期の状態のキャッシュは、一貫したリポジトリコピーで放出されるよりも異なる検証済みのペイロードを放出することにより、リスクをもたらします。[RFC9286]のセクション6.6に記載されている脱同期と_failed FETCH_メカニズムの相互作用により、当事者に依存することは、認定機関が撤回する予定の検証済みのペイロードを省略したり、検証済みのペイロードを発したりする可能性があります。その結果、非同期状態により、ルートの意思決定プロセスは、不確定期間にわたって「不明」または「無効」として有効であるとマークされることを目的としたルートアナウンスを検討する場合があります。 +

+
+
+
+
+

+Missing Validated Payloads negatively impact the ability to validate BGP announcements using mechanisms such as those described in [RFC6811] and [ASPA]. +

+
+
+

+検証済みのペイロードの欠落は、[RFC6811]や[ASPA]に記載されているメカニズムを使用してBGPアナウンスを検証する機能に悪影響を及ぼします。 +

+
+
+
+
+

+Section 6.6 of [RFC9286] advises RP implementations to continue to use cached versions of objects, but only until such time as they become stale. By detecting whether the remote Repository Server is in an inconsistent state and then immediately switching to using the latest Snapshot File, RPs increase the probability to successfully replace objects before they become stale. +

+
+
+

+[RFC9286]のセクション6.6は、RPの実装に、キャッシュバージョンのオブジェクトの使用を継続することをアドバイスしますが、それらが古くなるまでのみです。リモートリポジトリサーバーが一貫性のない状態にあるかどうかを検出し、最新のスナップショットファイルの使用に直ちに切り替えると、RPSはオブジェクトが古くなる前に正常に交換する確率を高めます。 +

+
+
+
+
+
+7. IANA Considerations +
+
+
+
+7. IANAの考慮事項 +
+
+
+
+
+

+This document has no IANA actions. +

+
+
+

+このドキュメントにはIANAアクションがありません。 +

+
+
+
+
+
+8. References +
+
+
+
+8. 参考文献 +
+
+
+
+
+
+8.1. Normative References +
+
+
+
+8.1. 引用文献 +
+
+
+
+
+ 
+   [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>.
+
+
+
+
+
+ 
+   [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>.
+
+
+
+
+
+ 
+   [RFC8182]  Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein,
+              "The RPKI Repository Delta Protocol (RRDP)", RFC 8182,
+              DOI 10.17487/RFC8182, July 2017,
+              <https://www.rfc-editor.org/info/rfc8182>.
+
+
+
+
+
+
+8.2. Informative References +
+
+
+
+8.2. 参考引用 +
+
+
+
+
+ 
+   [ASPA]     Azimov, A., Bogomazov, E., Bush, R., Patel, K., Snijders,
+              J., and K. Sriram, "BGP AS_PATH Verification Based on
+              Autonomous System Provider Authorization (ASPA) Objects",
+              Work in Progress, Internet-Draft, draft-ietf-sidrops-aspa-
+              verification-19, 27 September 2024,
+              <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
+              aspa-verification-19>.
+
+
+
+
+
+ 
+   [RFC6811]  Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
+              Austein, "BGP Prefix Origin Validation", RFC 6811,
+              DOI 10.17487/RFC6811, January 2013,
+              <https://www.rfc-editor.org/info/rfc6811>.
+
+
+
+
+
+ 
+   [RFC7115]  Bush, R., "Origin Validation Operation Based on the
+              Resource Public Key Infrastructure (RPKI)", BCP 185,
+              RFC 7115, DOI 10.17487/RFC7115, January 2014,
+              <https://www.rfc-editor.org/info/rfc7115>.
+
+
+
+
+
+ 
+   [RFC9286]  Austein, R., Huston, G., Kent, S., and M. Lepinski,
+              "Manifests for the Resource Public Key Infrastructure
+              (RPKI)", RFC 9286, DOI 10.17487/RFC9286, June 2022,
+              <https://www.rfc-editor.org/info/rfc9286>.
+
+
+
+
+
+
+Acknowledgements +
+
+
+
+謝辞 +
+
+
+
+
+

+During the hallway track at RIPE 86, Ties de Kock shared the idea for detecting this particular form of RRDP desynchronization, after which Claudio Jeker, Job Snijders, and Theo Buehler produced an implementation based on rpki-client. Equipped with tooling to detect this particular error condition, in subsequent months it became apparent that unexpected delta mutations in the global RPKI repositories do happen from time to time. +

+
+
+

+Ripe 86の廊下トラックで、Ties De Kockは、この特定の形式のRRDPデスンクロネ化を検出するためのアイデアを共有しました。この特定のエラー条件を検出するためのツールを装備して、その後数か月で、グローバルRPKIリポジトリの予期しないデルタ変異が時々起こることが明らかになりました。 +

+
+
+
+
+

+The authors wish to thank Theo Buehler, Mikhail Puzanov, Alberto Leiva, Tom Harrison, Warren Kumari, Behcet Sarikaya, Murray Kucherawy, Éric Vyncke, Roman Danyliw, Tim Bruijnzeels, and Michael Hollyman for their careful review and feedback on this document. +

+
+
+

+著者は、Theo Buehler、Mikhail Puzanov、Alberto Leiva、Tom Harrison、Warren Kumari、Behcet Sarikaya、Murray Kucherawy、Eric Vyncke、Roman Danyliw、Timan Bruijnzeels、Michael Hollymanの慎重なレビューとこの文書のフィードバックに感謝したいと考えています。 +

+
+
+
+
+
+Authors' Addresses +
+
+
+
+著者のアドレス +
+
+
+
+
+ 
+   Job Snijders
+   Fastly
+   Amsterdam
+   Netherlands
+   Email: job@fastly.com
+
+
+
+
+
+ 
+   Ties de Kock
+   RIPE NCC
+   Amsterdam
+   Netherlands
+   Email: tdekock@ripe.net
+
+
+
+
+ + +