ToppyMicroServices

RFC 1958 Quiz

変化を前提にしたInternet architecture

🇺🇸🇯🇵
0 / 0

References (URLs)

Q1: RFC 1958のprincipleはどう使うべきか

Multiple Choice
**Explanation:** A: 文書自身がformalでinvariantなreference modelではないと述べています. B: RFC 1958はInformationalであり,wire formatを定めません. C: 過去に有用だったguidelineを記録しつつ,constant changeと実装からのfeedbackを重視します.

Q2: RFC 1958が示すInternet architectureの高levelな見方はどれか

Multiple Choice
**Explanation:** A: global connectivityをgoalとし,IPとend-to-end intelligenceを手段とします. B: connectivityは個別applicationより価値があり,proprietary semantic gatewayは分断を招きます. C: 単一ownerなしで進化し,manual stateは最小化する考え方です.

Q3: network linkはerror detectionを行うが,applicationはobject全体が正しく届いたか確認したい.最終integrity checkを置く場所はどこか

Multiple Choice
**Explanation:** A: 一つのlink以外でもfailureは起こり,routerはapplication全体の正しさを判断できません. B: end-to-end functionを完全に検証できるのはendpointであり,lower layerの不完全なcheckも補助として役立ちます. C: central observationはapplication correctnessの必要条件でも十分条件でもありません.

Q4: RFC 1958に従うnetwork-maintained stateの性質はどれか.複数選択

Multi-Select
**Explanation:** A: adaptive procedureがあれば,topologyやactivityの変化後にstateを再構成できます. B: 永続的なper-session設定はguidelineに反し,endpoint communication stateをnetworkが脆弱に所有することになります. C: state量とmanual configurationを減らすと,operationとrecoveryのdependencyも減ります. D: 回復可能なstateなら,connectivityが残る場合のlossをtemporary disruptionへ限定できます.

Q5: 二つのprotocol proposalに説得力あるarchitecture文書はあるが,interoperating implementationはない.まだ不足しているものはどれか

Multiple Choice
**Explanation:** A: Internetには単一ownerがおらず,cooperationで進化します. B: optionはambiguityと実装負担を増やします. C: RFC 1958はrough consensusとrunning codeを重視し,real implementationからのfeedbackはarchitecture principleだけより重要だとします.

Q6: 新protocolが,peerのCPU,memory,bandwidth,application timingがほぼ同じ場合にしか動かない.RFC 1958の最も直接的な懸念はどれか

Multiple Choice
**Explanation:** A: Internet protocolはhost,link,applicationの大きな差を扱う必要があります. B: Internet layerはhardware mediumとhardware addressingから独立させます. C: 共通layerを一つのapplicationへ最適化せず,多様なapplication protocolを支えます.

Q7: 配備済みmechanismと同じ問題を解く非互換mechanismを,technical advantageの証拠なしに追加しようとしている.望ましいreview outcomeはどれか

Multiple Choice
**Explanation:** A: 機能重複はinteroperabilityとmaintenanceのcostになります. B: technical improvementが変更を正当化しない限り,成功した既存解を選びます. C: parameter数は価値ではなく,不要なoptionは避けるべきです.

Q8: RFC 1958のgeneral design guidanceに合うdecisionはどれか.複数選択

Multi-Select
**Explanation:** A: 分離できるresponsibilityをmodularに保つと,変更の影響範囲を閉じられます. B: 現在使えるsimpleなsolutionは,無期限に待つperfect designでは得られないimplementation feedbackを生みます. C: optionとparameterは可能な限り避け,必要ならmanual configurationよりdynamic negotiationを使います. D: 機能してもscaleしない,またはcostが高すぎるdesignはInternet designとして不十分です.

Q9: routingの起動にDNS lookupが必要だが,DNS serverへ到達するにはroutingが必要である.RFC 1958はこの設計をどう分類するか

Multiple Choice
**Explanation:** A: fate sharingはcommunication stateをendpointと共に置く考えで,startup deadlockの正当化ではありません. B: 可読性はbootstrap failureを解決しません. C: routingがDNSに依存する例は,RFC 1958が明示するcircular dependencyです.

Q10: Agent-to-Agent serviceがprivate carrier linkを信頼し,endpointでintegrityもpeer authenticationも確認しない.RFC 1958に基づくreview conclusionはどれか

Multiple Choice

carrierはそのsegmentを保護できますが,applicationはpath全体とpeer agentについてのassuranceを必要としています.

**Explanation:** A: RFC 1958はconfidentialityとauthenticationの責任をend user側に置き,carrierのconfidentialityやintegrityへ依存しないよう求めます. B: linkやcarrierのtrustはapplication identityやauthorizationを確立しません. C: endpoint identity stateをnetworkへ移すとcouplingが増え,fate sharingを弱めます.