Summary

  • Revision 09 of the L2VPN snooping extension refreshed the document date and expiry but left the normative text and embedded 2022 YANG revision unchanged.
  • The module imports an L2VPN model whose cited revision expired in 2020, so a current document timestamp does not establish a current, resolvable dependency set.
  • Decision-grade evidence must connect exact modules and imports to compilation, device support, authorised change, applied state and packet-level forwarding results.

At first glance, the update is ordinary standards maintenance. The Datatracker record now shows revision 09 of IGMP and MLD Snooping Yang Module Extension for L2VPN. The draft extends the RFC 9166 snooping model, which originally described bridge service, so that an IGMP or MLD snooping instance can be attached to an L2VPN network instance.

The mechanism is concrete. Static attachment circuits and pseudowires can be named as multicast-router or outgoing interfaces. Read-only leaves can report interfaces learned dynamically. A service reference connects the snooping instance to the L2VPN. This is not policy poetry; it is a proposed machine-readable surface.

Yet revision 09 also exposes a lifecycle problem that the green “current” status cannot answer. A comparison of the revision 08 text and revision 09 text changes the cover date, draft number and expiry. The model still declares revision 2022-10-11. More importantly, it imports ietf-l2vpn and ietf-pseudowires by reference to draft-ietf-bess-l2vpn-yang-10.

The dependency's Datatracker record says revision 10 was last updated in January 2020 and expired that month. The archived dependency text remains inspectable, so expiry does not prove that the model is technically wrong. It proves something narrower and more important: the freshness of the importing document does not establish the freshness, stability or implementation status of the imported contract.

Four dates, four different claims

The Datatracker update time, the date printed on the draft, the YANG revision statement and the lifecycle state of an imported module are not interchangeable. One says when a database record changed. One belongs to the submitted document. One identifies the model revision. One says whether a referenced working document remains active.

Collapsing them produces a familiar management error. A procurement note says “the draft was updated this week”; a roadmap turns that into “the model is current”; an automation team hears “the interface is stable”; an operations review records “the feature is ready.” Every sentence may descend from a true timestamp, while none has proved the next conclusion.

This is the reality-layer distinction in Heng Lu's analysis: a symbol is useful only when it does not impersonate the operational result. A refreshed document is evidence about a document. It is not a compiler receipt, a device capability statement or a multicast delivery test.

The model contains requests and reports, not outcomes

The draft's config true leaves request static mrouter and outgoing AC/PW state. Its config false leaves report what the device says it learned. RFC 8342 makes the missing steps explicit. Running configuration can require transformation. Intended configuration is what the system attempts to apply. Operational state combines applied configuration with system state. A valid intended reference can remain absent from operational state when the required resource does not exist.

Even operational state is not the customer outcome. A reported pseudowire member does not prove that one multicast stream was replicated to every intended receiver, suppressed from uninterested sites, preserved across churn or restored after rollback. That requires packets, counters and timing observed at the relevant boundary.

The access boundary is separate again. RFC 8341 distinguishes read, create, update, delete and execute authority. A leaf marked writable describes a possible operation; it does not name the principal permitted to perform it. The draft's security section warns that unauthorised writes can send packets to inappropriate destinations, while unauthorised reads can disclose snooping state. Transport security protects a management session, not the correctness of the requested replication graph.

A thin closure receipt

The right response is not to demand that the IETF certify each vendor. That would replace one category error with another. The standards process can define names, structure and interoperable semantics. Operators and suppliers must show how those semantics close in a particular system.

A minimum receipt starts with the exact draft or RFC, embedded module revision and every imported module revision. It records the validator and deviations, the software release and advertised feature set, then the NACM principal and operation. It captures running, intended and operational state before and after the change. Finally, it tests IGMP/MLD learning and actual replication across both attachment circuits and pseudowires, including a negative check that traffic does not flood where no member exists. Rollback must show whether remnant configuration or learned state survived.

That is a practical use of Minimum Initial Specification: keep the common proof thin enough to compare, and leave the local implementation decision with the party operating the network. It also preserves running-code primacy. The model can guide the test; it cannot announce its result.

Revision 09 may be only an administrative refresh before substantive work. The expired dependency may have implementations or successors outside this source set. Vendors may expose equivalent functions under private models. None of those possibilities repairs the inference automatically. They are reasons to ask for the missing receipt.

The draft was new. That was one fact. The dependency graph, authorisation and forwarding result remained different facts. Leadership becomes expensive when a current timestamp is allowed to bind them together.

Sources

  1. Current extension draft record
  2. Extension draft revision 09
  3. Extension draft revision 08
  4. L2VPN YANG dependency record
  5. L2VPN YANG revision 10
  6. RFC 9166
  7. RFC 8342
  8. RFC 8341
  9. RFC 4541
  10. Reality Layers
  11. Running-Code Primacy
  12. Minimum Initial Specification