[OPSAWG][VELOCE] Discussion (2/3): How should an RFC reference a YANG module in a git repository?

[Mahesh Jethanandani <[e-mail]>]

Forgot to mention in my first email that I am posting this on behalf of all the authors of the draft. Sorry, not acknowledging them.

Hint to the WG Chairs. The options being presented here for each question will make for a good poll in the WG meeting

Series note: This is the second of three emails on open VELOCE issues. The first covered platform choice. The third will cover proposed issue sequencing. All three topics will be presented and discussed at the upcoming IETF meeting in Vienna.

Dear OPSAWG participants,

The VELOCE experiment proposes that YANG modules live in a git repository rather than being embedded verbatim in the RFC body. When an RFC is published under this model, it contains a pointer to the repository rather than the full module text. This raises three closely related questions that issues #3, #7, and #20 have been discussing without yet reaching a resolution.

1. WHAT DOES THE RFC POINTER LOOK LIKE?

At the time of publication, the YANG module is at a specific version in the repository. The RFC needs to capture that version permanently. Issue #20 proposed boilerplate along the lines of:

"The YANG module at the time of publication of this RFC is available at [TAG-URL]. For the latest version of the module, see [LATEST-URL]."

The format and target of both URLs remain open. Should [TAG-URL] be a git tag URL, an IANA registry entry, or something else? Should [LATEST-URL] point to a specific branch (such as main), to an IANA registry entry, or to something the WG maintains separately?

2. WHICH VERSION SHOULD AN IMPLEMENTOR TARGET?

Once a module can be updated post-publication, the RFC simultaneously points to a frozen publication-day version and a living latest version. If an implementor wants to be compliant, which should they implement? The options are:

The publication-day version only (strictest — equivalent to current practice)

The latest tagged release, provided it is backward-compatible with the publication-day version

Any version, at the implementor's discretion

3. WHAT DOES "CONFORM TO THIS MODULE" MEAN?

Issue #3 asks exactly this. In current practice, conformance means implementing the module as it appears in the RFC — a stable, immutable target. Once the module can change, conformance becomes ambiguous. We need an explicit definition that test suites and interoperability events can use.

QUESTIONS FOR THE WG

Is the WG comfortable with the pointer-in-RFC model, or is there a strong preference to keep YANG modules embedded in the RFC body?

If we use a pointer, what should [LATEST-URL] point to?

How should conformance be defined once a module can be updated post-publication?

Please share your views on the list. These questions will also be discussed at the upcoming IETF meeting in Vienna, and your mailing-list input will directly inform that session.

Posting on behalf of all the authors.

Mahesh Jethanandani
[e-mail]