RFC 5218 Quiz

From specification to deployment

0 / 0

References (URLs)

Scope: RFC 5218 is an Informational case-study analysis. Its success factors are design-review questions, not protocol conformance requirements or guarantees of adoption. Security claims still require their own specification and verification.

Q1: Which result qualifies as protocol success in RFC 5218's working definition?

Multiple Choice
**Explanation:** publication is not deployment success. RFC 5218 evaluates both achievement of original goals and wide deployment; “wide” can be intra-domain. implementation evidence matters, but one lab test does not establish broad use.

Q2: Which review conclusion best follows from RFC 5218's positive-net-value analysis?

Multiple Choice

An A2A profile benefits client-software vendors, but every operator must replace its gateway and identity provider before any deployed agent receives that benefit. No operator has committed to the migration.

**Explanation:** RFC 5218 Sections 2.1.1 and 2.1.2 favor positive net value at each organization required to change and benefit for early adopters, so B identifies the concrete adoption weakness without predicting the outcome. A ignores cost/benefit misalignment. C is too strong: Section 1.4 says failure cannot be determined before sufficient time and opportunity for implementation, deployment, and use. These are empirical success factors, not conformance rules.

Q3: Which rollout best combines incremental deployment with an explicit security boundary?

Multiple Choice

A sender-bound authorization mode is optional. One administrative domain wants to deploy it while continuing ordinary task exchanges with legacy peers.

**Explanation:** A gives an early adopter intra-domain value, avoids a flag day, and keeps fallback semantics explicit, matching Section 2.1.2's deployment factors. B maximizes coordination dependencies. C changes a security claim on failure; RFC 5218 does not authorize that equivalence, which belongs in the security profile. Incremental deployability improves adoption prospects, not security by itself.

Q4: Which comparison applies RFC 5218 without overstating it?

Multiple Choice

Two A2A discovery profiles have comparable benefit and deployment cost. A has a stable public specification and freely available implementation. B is available only through one vendor's per-use licensed SDK. Neither has deployment evidence.

**Explanation:** Section 3 says open specifications and code become significant when benefit and deployability are comparable; Sections 2.1.3–2.1.5 also identify code availability, freedom from usage restrictions, and specification availability. A is therefore the supported probabilistic comparison. B reverses those factors without evidence. C confuses openness with verified interoperability and security, neither of which RFC 5218 guarantees.

Q5: Which design-review statement is justified by RFC 5218's case studies?

Multiple Choice

Profile A is technically cleaner but needs coordinated replacement of all brokers. Profile B is less elegant, solves an urgent niche for one domain, and works beneath existing unmodified applications.

**Explanation:** Sections 2.1.1, 2.1.2, and 3 identify real need and incremental deployability as the strongest initial factors, making B the careful prediction. Section 2.1.7 still treats simplicity, modularity, robustness, and clarity as valuable, especially after initial success. A reverses the observed weighting. C wrongly treats early adoption as proof of continued success and ignores Sections 1.3 and 2.2.

Q6: What is the most defensible extensibility decision under RFC 5218?

Multiple Choice

A narrowly scoped audit-export protocol carries one fixed record type. A proposal adds arbitrary executable extension payloads solely because it might someday be reused for unrelated workflows.

**Explanation:** Section 2.2.1 links extensibility to use beyond the original purpose but says it should be carefully considered for specialized protocols, so B states the actual trade-off. A invents a requirement and ignores cost. C is also absolute: extensions can enable later uses and repairs. RFC 5218 neither chooses an application-specific mechanism nor authorizes executable payloads.

Q7: Which review finding most precisely addresses the scaling evidence?

Multiple Choice

An agent-discovery protocol broadcasts to every participant. Tests show a broadcast-storm collapse at 5,000 nodes; the planned first deployment has 4,500.

**Explanation:** Section 2.2.2 explicitly treats a performance “knee” causing meltdown near the envisioned scale as a hard scalability bound, so A is precise. B confuses an initially usable range with room for much larger scale. C confuses syntactic extensibility with a remedy; the algorithm is unchanged. The RFC identifies a risk factor, not a mandatory threshold.

Q8: Which response treats wild success as a design-review problem?

Multiple Choice

A task-approval protocol designed for low-value internal jobs is now used for payments and medical-device actions. Implementers added incompatible fields, and attackers can profit from ambiguous approvals.

**Explanation:** Sections 1.2 and 1.3 define wild success as growth beyond the original purpose or scale and warn of inappropriate assumptions, invariant-breaking changes, performance problems, and increased attacker value. C addresses those risks without inferring safety from popularity. A makes that unsupported inference. B is wrong because Section 1.3 says wild success may indicate that revision is timely. The RFC frames the review; it does not supply payment or medical authorization policy.

Q9: Which conclusion properly separates initial success from survival?

Multiple Choice

A widely deployed protocol has a credential-replay flaw. A negotiated extension can repair it, but most deployed peers do not yet implement the extension.

**Explanation:** Sections 2.2.3 and 3 observe that vulnerabilities may not block initial adoption while a popular protocol becomes a more valuable target; extensibility helps only if flaws can actually be addressed. B preserves that distinction and identifies the remaining deployment problem. A treats popularity as security evidence. C treats potential extensibility as an effective mitigation before the installed base deploys or enforces it.

Q10: Which combined assessment is supported by RFC 5218?

Multiple Choice

Plan A publishes a sender-bound authorization profile and test code. One domain can negotiate it for an urgent use while legacy exchanges retain explicitly weaker semantics. Plan B has a stronger new mechanism, but its closed SDK requires every agent, broker, gateway, and identity provider to migrate together.

**Explanation:** Plan A addresses a real need, gives one adopter early value, avoids a flag day, and provides open specification and code—the initial factors in Sections 2.1 and 3. A is therefore the supported adoption comparison and correctly refuses to infer security from adoption conditions. B overweights technical quality and ignores cost, restrictions, and coordination. C misstates incremental deployability: compatible operation can improve it when the modes' different guarantees are explicit. RFC 5218 predicts neither adoption nor sender-binding correctness.