ToppyMicroServices

RFC 1958 Quiz

変化を前提にしたInternet architecture

🇺🇸🇯🇵
0 / 0

References (URLs)

Q1: RFC 1958 Section 2.3を設計レビューの視点として使う場合,RFCから言える範囲に収まる結論はどれか

Multiple Choice

gatewayがgrantとsession-bound proofを検証し,proof_valid=true,対象resource,freshness情報を含む署名済みassertionをbackendへ渡します.resourceを所有するbackendが最終的なauthorizationを判断しますが,元のgrantとproofは検証できません.gatewayを信頼するsecurity endpointとして扱うか,assertionをbackend requestへどう結び付けるかは未定義です.

**Explanation:** A: RFC 1958はInformationalの設計指針であり,protocolの適合性要件ではありません.Section 2.3も中間ノードによるsecurity処理を一律に禁じていません. B: 認証されたassertionはtrusted gateway構成の証拠になり得ますが,署名とfreshnessだけでは,どのrequest,session,resource,判断を対象にするかは決まりません. C: 正解です.end-to-end argumentは,必要な知識を持つ場所で完全な機能を実現できるかを問います.backendが直接検証する設計も,trusted gatewayのassertionに依存する設計もあり得ます.後者では,gatewayのidentityとtrust,assertionのintegrity,requestとresourceへのbinding,freshness,replay処理,backendのauthorization責務を定義する必要があります.RFC 1958だけではtrust modelを選べず,どちらかを適合・不適合とも断定できません. D: componentの呼び方だけでは保証の契約は生まれません.assertionが何を証明し,最終確認をどこで行うかをarchitectureで定義する必要があります.

Q2: RFC 1958 Sections 2.1 and 2.3から,この設計へ最も適切に提起できる懸念はどれか

Multiple Choice

異なる事業者のA2A endpointはIPでは到達できますが,特定事業者のgatewayだけがtask stateとauthorizationを相互変換できます.要件は,そのgatewayの停止または事業者変更後もendpoint間で同じ意味を復元できることです.

**Explanation:** A: Sections 2.1と2.3はgateway processingを一律に禁じる規範ではありません.gatewayをapplication endpointにする設計もあり得ます. B: endpointの分類はfailure requirementを消しません.gateway停止後に誰がsemanticsを復元するかが未解決です. C: 指摘できるのは,必要なend-to-end functionとstateが単一dependencyに置かれ,明示要件を満たせないことです.RFC 1958は具体的な変換protocolやtrust modelを選びません. D: packetの到達性とapplication-level interoperabilityは同じではありません.なおSection 2.2のone Internet-level protocolはこのapplication gateway問題の直接根拠ではないため,参照から外しています.

Q3: RFC 1958 Section 2.3を使ったintegrity reviewとして,最も適切な判断はどれか

Multiple Choice

agentが2 GB artifactのexact octet sequenceを承認します.gatewayはchunkへ分割し,object storeで再構成します.各hopはTLSとchunk checksumを使います.backendの要件は,再構成したoctetsが承認時と同一であることの確認です.

**Explanation:** A: 各hopの成功記録は区間ごとの伝送を説明しますが,分割・保存・再構成を通じたexact octetsの同一性を直接覆いません. B: backendが必要とする完全な機能を,承認者からbackendまで同じoctet sequenceを対象に確認します.hop checkは補助として両立します. C: gateway署名はgatewayが見たoctetsを示せても,元の承認対象との一致は別のbindingがなければ示しません. D: 完了とsizeは必要なoperational evidenceになり得ますが,内容の一致を確立しません.RFC 1958はdigest方式を指定せず,ここでは前提のexact-octet requirementに適用しています.

Q4: RFC 1958 Section 2.3をreview lensにすると,どのstate配置が要件へ最も直接対応するか

Multiple Choice

task ownerはauthoritativeなtask stateとresume cursorをdurableに保持します.relay clusterはsubscriber mappingだけを持ちます.要件は,relay cluster全体を失ってもauthoritative cursorを失わず,再接続後30秒以内にstreamを再開できることです.

**Explanation:** A: process failureへのavailabilityは上げられますが,前提のcluster全損ではauthoritative sourceが残りません. B: durable storeでも要件を満たす設計は可能ですが,二つのauthorityの整合とfailure dependencyが増えます.その必要性は前提から示されていません. C: authoritative stateの寿命をtask ownerへ揃え,relay stateをself-healingにします.replicationは復旧時間を短縮する補助として併用できます. D: agentのcursorをauthorityにすると,replayやrollbackを含む別のtrust problemが生じます.Section 2.3は特定databaseや30秒という値を決めず,stateのfateと再生成可能性を評価する視点を与えます.

Q5: RFC 1958 Sections 2.4 and 3.14を踏まえ,claimとevidenceの対応として支持できるものはどれか.複数選択

Multi-Select

A2A profile Xは二つの独立実装がloss,並べ替え,version mismatchを含む試験で相互運用しました.profile Yは詳細なformal modelを持ちますが,実装は一つだけです.どちらも大規模運用と攻撃耐性は未評価です.

**Explanation:** A: 支持できます.観測範囲を限定したinteroperability claimです. B: 支持できません.試験していないsecurityとscaleへ外挿しています. C: 支持できます.formal evidenceはmodelとassumptionの範囲で評価します.running codeと競う単一順位ではありません. D: 支持できます.RFC 1958はimplementation feedbackを重視しますが,標準化手続や未評価claimの成立を自動的に決めません.

Q6: RFC 1958 Sections 3.1, 3.3, and 3.4をreview lensにした結論はどれか

Multiple Choice

profileはmobileを含む公開Internet上のA2Aを対象としますが,固定200 ms deadline,最低8 MB buffer,高頻度heartbeatを要求します.datacenter試験は成功し,mobileではtimeoutし,100万のidle agentではcontrol trafficが支配的になりました.

**Explanation:** A: 観測結果とInternet-wide claimが一致しません.datacenter限定profileなら同じ値を正当化できる可能性があります. B: 原則から指摘できるのはscopeとevidenceの不一致です.固定値を禁止するのではなく,対象環境に合わせて設計・測定するか,claimを限定します. C: option化は一案ですが,negotiationとfailure semanticsが未定義なら相互運用性を改善しません. D: Sections 3.3と3.4はscale,performance,costもdesign reviewの対象にします.RFC 1958は具体的なdeadlineやthresholdを決定しません.

Q7: RFC 1958 Section 3.2から導けるreview conclusionはどれか

Multiple Choice

既存のAgent Card discoveryは広く配備されています.新方式は検索時のmetadata leakageを試験で60%削減しましたが,18か月のdual lookupと追加実装が必要です.残るfailure rateとprivacy benefitの許容thresholdは未合意です.

**Explanation:** A: Section 3.2は既存解の再利用を勧めますが,改善を拒否するために使うべきではないと述べます. B: benefitだけではecosystem全体の相互運用性と移行riskを評価できません. C: supported.「既存方式で不可能な機能」だけでなく,privacy,performance,operationの測定可能な改善もgood technical reasonになり得ます. D: 永続的な重複はSection 3.2が避けようとするcostを残します.RFC 1958だけでは60%や18か月を採用thresholdとして決定できません.

Q8: RFC 1958 Sections 3.5, 3.6, and 3.8を使ったreviewで最も支持しやすい改訂はどれか

Multiple Choice

低帯域deviceとdatacenterの両方を支えるためvariationは必要です.現行profileには相互作用する14個のmanual flagがあり,operator間の設定不一致が障害の40%を占めます.三つの相互運用可能なcapability bundleは試験済みです.

**Explanation:** A: recommendationだけでは前提のmanual coordination failureを解消しません. B: option spaceは減りますが,明示されたheterogeneity requirementを満たしません. C: 必要なvariationを残しつつ,option spaceと手動設定を減らします.具体的なbundle数やfallback semanticsは別途profileが定義します. D: 有効な組合せを増やすほど実装・試験matrixが広がります.Section 3.7のalmost complete solutionは,相互運用に必要な動作を未定義にしてよいという意味ではありません.

Q9: RFC 1958 Section 3.11でcycleを指摘した後,前提を満たすbootstrap案はどれか

Multiple Choice

Agent Cardの取得にはOAuth tokenが必要ですが,token endpointを知る唯一の方法もそのCardです.clientにissuerの事前設定はありませんが,対象agentのDNS nameは既知で,DNSとWebPKIをbootstrap trustとして利用できます.

**Explanation:** A: 利用可能なtrust anchorでbootstrap metadataを認証し,tokenとCardのcycleを切ります. B: cycleは切れてもmetadata substitutionを防げません.後続tokenは過去の取得元を自動認証しません. C: credential disclosureとissuer confusionを招きます.issuer選択には認証済みmetadataまたは事前設定が必要です. D: 両requestが互いの未取得情報を必要とするため,並列化ではcycleを解消しません.Section 3.11はcycleを避ける指針を与えますが,`.well-known`形式やWebPKIの詳細は別仕様とtrust policyが決めます.

Q10: RFC 1958 Sections 6.3-6.5だけを根拠に支持できるreview conclusionはどれか

Multiple Choice

profile v1はAlgorithm Aだけを固定し,署名対象にalgorithm identifierを含めません.Algorithm Bへの移行案は,integrity保護されないheaderでAまたはBを指定します.異なる実装間のsecure interoperabilityも必要です.

**Explanation:** A: Section 6.3はalternative algorithmsを許す設計と,使用algorithmの明示labelを述べます.固定だけでは両方を満たしません. B: supported.これはSections 6.3-6.5が述べる範囲と,述べない範囲を分離しています. C: Section 6.5はsecure contextの相互運用のため一つの共通algorithmまたはsuiteを設ける考えを示します. D: explicit labelの存在だけでは書換えへの耐性を確立しません.ただしlabelをcryptographic scopeへ入れる方法,downgrade防止,現在許可するalgorithmはRFC 1958本文だけでは決まらず,利用する署名仕様,現代のsecurity guidance,local policyが必要です.