Context
transports/quic.md, lines 69-72:
"a client MAY instead pin the endpoint certificate, by exact DER or by its SHA-256 fingerprint, when that pin is supplied through the application's out-of-band watch configuration."
Defect
"The application's out-of-band watch configuration" is used exactly once in the whole repo (verified by grep) and is never defined — not in quic.md, not in the companion feature docs, not in implementation-model.md.
Failure scenario
Implementers have no spec-defined mechanism for how a certificate pin is supplied or scoped, making cert-pinning interop-inconsistent — one implementation might scope pins per-group, another per-account, another globally, with no way to tell which the spec intends.
Suggested fix
Either define what "out-of-band watch configuration" means (its scope, how a pin is supplied/updated), or rephrase to explicitly say this is local, application-defined configuration outside the spec's scope, so readers don't search for a definition that doesn't exist.
Context
transports/quic.md, lines 69-72:Defect
"The application's out-of-band watch configuration" is used exactly once in the whole repo (verified by grep) and is never defined — not in
quic.md, not in the companion feature docs, not inimplementation-model.md.Failure scenario
Implementers have no spec-defined mechanism for how a certificate pin is supplied or scoped, making cert-pinning interop-inconsistent — one implementation might scope pins per-group, another per-account, another globally, with no way to tell which the spec intends.
Suggested fix
Either define what "out-of-band watch configuration" means (its scope, how a pin is supplied/updated), or rephrase to explicitly say this is local, application-defined configuration outside the spec's scope, so readers don't search for a definition that doesn't exist.