Observation
RFC 0005 config seeding (merged, #268): the drtp fetch server unconditionally sends drtp-config-v1 and folds the source's config-log-head blob into the transferred blob set. But a network pull is also a fetch — so a drtp pull receives the config blob (when it doesn't already hold it) and then discards the descriptor, because seeding is clone-only.
Effect: a minor, harmless inefficiency — an extra blob transferred to the puller's store on pull (skipped by have-negotiation when already held; otherwise it's a dangling, GC-able config blob). No correctness or test impact (the full suite is green).
Note the HTTP backend does not have this issue: the http client only issues GET /config on clone, so http pulls never fetch config. The asymmetry is drtp-only.
Suggested fix
Make config transfer genuinely negotiated (which RFC 0005's abstract already calls it): add a want-config (clone-only) flag to drtp-want-v1; the fetch server folds the config blob + sends drtp-config-v1 only when the client requested it. Clone sets the flag; pull doesn't. This matches RFC 0004's "MUST NOT assume a feature unless advertised" model and brings drtp to parity with the http client's clone-gating. Update RFC 0005's drtp §Server obligations accordingly (currently specifies unconditional send on fetch).
Environment
amarbel-llc/dodder master; drtp config seeding in sierra/remote_proto (sendClosure / drtp-want-v1), RFC docs/rfcs/0005-config-seeding-over-remote-transfer.md.
🤡 Filed with Clown 0.3.11+1a69402 (amarbel-llc/clown@1a69402)
Observation
RFC 0005 config seeding (merged, #268): the drtp fetch server unconditionally sends
drtp-config-v1and folds the source's config-log-head blob into the transferred blob set. But a networkpullis also a fetch — so a drtp pull receives the config blob (when it doesn't already hold it) and then discards the descriptor, because seeding is clone-only.Effect: a minor, harmless inefficiency — an extra blob transferred to the puller's store on pull (skipped by have-negotiation when already held; otherwise it's a dangling, GC-able config blob). No correctness or test impact (the full suite is green).
Note the HTTP backend does not have this issue: the http client only issues
GET /configon clone, so http pulls never fetch config. The asymmetry is drtp-only.Suggested fix
Make config transfer genuinely negotiated (which RFC 0005's abstract already calls it): add a
want-config(clone-only) flag todrtp-want-v1; the fetch server folds the config blob + sendsdrtp-config-v1only when the client requested it. Clone sets the flag; pull doesn't. This matches RFC 0004's "MUST NOT assume a feature unless advertised" model and brings drtp to parity with the http client's clone-gating. Update RFC 0005's drtp §Server obligations accordingly (currently specifies unconditional send on fetch).Environment
amarbel-llc/doddermaster; drtp config seeding insierra/remote_proto(sendClosure/drtp-want-v1), RFCdocs/rfcs/0005-config-seeding-over-remote-transfer.md.🤡 Filed with Clown 0.3.11+1a69402 (amarbel-llc/clown@1a69402)