Summary

  • Broadband Forum told the IETF that WT-477i2 depended on the BGP YANG modules and asked for target publication-date information. That establishes an external dependency and a request, not an IETF delivery commitment.
  • IDR’s August liaison said the draft was in Working Group Last Call and named later Area Director, IETF-wide Last Call and IESG review steps before entry into the RFC Editor publication queue.
  • A 21 August message from the responsible Routing Area Director says the WGLC remains open and that silence does not indicate readiness to publish. Positive support and completed reviews are still relevant to judging consensus.
  • The current Datatracker entry identifies version 21 as an Internet-Draft, with a Working Group state of “Waiting for Implementation,” an IESG state of “I-D Exists,” and no telechat date. None is an RFC publication record.
  • The useful public control is a dependency-aware state receipt: it must join the BBF deliverable/version to the IETF draft/version and preserve each review and disposition stage without converting one into another.

The dependency is real, and it has a narrow meaning

The Broadband Forum’s December 2025 liaison is not vague about its position. It says the YANG data models developed in its WT-477i2 draft depend on the named ietf-bgp model and associated modules then represented by draft-ietf-idr-bgp-model-18. It attaches a draft for IDR’s consideration, explains that WT-477i2 was nearing completion, and asks for information about a target publication date for the IETF model.

That is a useful institutional act. It tells readers which external document is dependent, which IETF work it names, and why the requester seeks schedule information. It also identifies the dependency as BBF’s own account of its release position. It does not create a deadline inside the IETF, reserve an RFC number, transfer a publication decision to BBF, or prove that a technical dependency has already been resolved in a deployed implementation.

The distinction matters because standards dependencies are normal. A model may be useful to a second standards body precisely because both bodies prefer not to recreate the same technical vocabulary. But avoiding duplication does not justify collapsing two processes. A downstream document can need an upstream specification without acquiring authority over its remaining reviews. The requester has a legitimate interest in visibility; the reviewing group still has to establish the state that its own process requires.

IDR answered a scheduling question with a process boundary

The IDR response of 1 August says that draft-ietf-idr-bgp-model was in Working Group Last Call. It then states the steps still expected after the working-group call: Area Director review, IETF-wide Last Call, and comprehensive IESG review before the document enters the RFC Editor publication queue. The response says those later stages can take substantial time. Crucially, it does not translate that observation into a date.

Its other advice is just as important. Interested Broadband Forum participants are encouraged to join the IDR mailing list, provide technical feedback, discuss the document and state support. Those are routes for contribution. They are not a substitute for the review record, an automatic consensus result or a published standard.

The public list adds a more current constraint. On 21 August, the Routing Area Director explained that version 21 had been posted, that the WGLC remained open, and that silence would not be counted as readiness to publish. The message says that positive support and completed reviews would inform the consensus judgment. It also notes that the three IDR chairs are co-authors and that the Area Director would call consensus for this WGLC, with a named shepherd for review.

That is not institutional theater. It tells a reader exactly what an open review means. An existing working-group document, a version upload, participation on a list and the absence of an objection do not all carry the same evidentiary weight. The record identifies a person with the relevant process role, the kind of evidence being sought and the state that remains unsettled.

A draft record is not an RFC record

The version-21 Datatracker page currently labels the work an Internet-Draft, gives it a 14 August 2026 version date and says Internet-Drafts are working documents that may be updated, replaced or obsoleted. Its status display lists “Waiting for Implementation” for the Working Group, “I-D Exists” for the IESG and no telechat date. The draft itself says it is inappropriate to cite it other than as work in progress.

Those fields do not diminish the work. They stop readers from treating one type of maturity as another. The IDR charter puts BGP maintenance at the centre of the group’s purpose, but a charter identifies the group’s task, not the outcome of every individual document. RFC 2026 describes standards-track maturity and says a specific IESG action is required to move a specification to Proposed Standard. Even then, experience may still alter or retract the work before it advances.

The process therefore has several non-substitutable proofs:

  1. BBF can document that its work depends on a named draft version.
  2. IDR can document the draft’s working-group review state.
  3. Reviewers and the responsible process role can document whether the evidence supports a consensus disposition.
  4. Later IETF and IESG records can document their own reviews and decisions.
  5. The RFC Editor can document queue entry and, eventually, publication.

Each record answers a different question. A BBF dependency answers “what does this downstream work need?” A WGLC answers “what working-group review is open?” An RFC answers “what has actually been published?” Confusing them may make a schedule sound simpler, but it makes the public state less true.

The minimum receipt should preserve the joins

The solution is not a speculative timeline or a demand that one organization publish another’s internal calendar. It is an attributable, versioned receipt. For this dependency, the receipt should hold at least: the BBF document and version; the exact IETF draft/version it references; the date and terms of the dependency notice; the WGLC state and its opening, continuation or close record; completed reviews and the consensus disposition when it exists; each later IETF and IESG state; any RFC Editor queue entry; and the final RFC, if published.

Every row should also carry a negative boundary. A dependency row does not prove an IETF commitment. A WGLC continuation does not prove non-publication forever. A support message does not by itself prove consensus. An RFC Editor queue row does not prove a downstream document’s release. A final RFC does not establish adoption, interoperability or operational use of WT-477i2.

That last discipline is especially important around BGP. The public sources here describe document state and process. They do not show a carrier deployment, a vendor conformance result, a customer network, an implementation test or a service impact. A governance article should not manufacture those outcomes from a technical draft’s existence.

What the record does not permit

There is no public basis here to predict the final publication date, assign blame for elapsed time, or infer a dispute between BBF and IDR. The August liaison is responsive and process-specific. The later WGLC update says review is still open. Neither says the draft has failed, that BBF’s own work is flawed, or that a fixed schedule has been accepted.

The record also does not allow a reader to reverse the authority chain. An external standards body can contribute expertise and identify a dependency. Its participants may offer feedback through the designated public route. But the review and standards disposition remain records of the IETF process. Conversely, an IETF status does not become a statement about BBF’s eventual editorial or product decision.

That boundary is not a delay tactic. It is how a technical coordination system keeps a real dependency from becoming a fictional mandate.

Sources