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

[Michael Richardson <[e-mail]>]

Italo Busi <Italo.Busi=[e-mail]> wrote:
    > I think we can resolve all these issues by always publishing a short
    > RFC-update which just updates the [TAG-URL]

No.

1. While the assymptotic effort of publishing an RFC is O(length), there is a
   very large constant overhead even for a 1 page RFC.  Eliminating/reducing that
   large constant is the goal here.


2. This does not address the question of how the YANG module is referred to
   in the original RFC, such that it can be updated.

Right now, we pass by value (inline), and we need to pass by reference.

    > 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?

I proposed that it refer to an IANA Registry, with an IESG Action consideration.
The IESG would then be in full control of updating the contents of the
indirection table.
So, it's not a TAG-URL exactly.

It would give the _YANG module ietf-foobar_ [ref], where [ref] is a normative
reference to the IANA YANG Module registry itself.

https://github.com/mjethanandani/veloce/pull/49/changes

This process is similiar to how we advance PS->STD, when no document changes
are neededed.   v6ops did this for
RFC7755 with https://datatracker.ietf.org/doc/draft-palet-v6ops-siit-dc-st/00/
It's not through the IESG, AFAIK.
Note that it still has to gain WG Consensus, AD review, and maybe even
sectorial review.  But, word smithing and detailed editing is not important.

    > 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:

I guess that this refers to the source of the data (the router control
plane).   Not the NMS or other thing that speaks *CONF and uses YANG.

The implementor should implement the *oldest* version of the module which
covers all of the attributes that their implementation ... implements.
That retains as MUCH compatibility with existing NMS as possible.
Naturally, if router platform FOOBAR's BGP module now implements (picking
something at random) v4-next-hop-v6, and one needs at least YANG MODULE
20260215 to describe that, then that's the minimum version.


--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

**       My working hours and your working hours may be different.         **
** Please do not feel obligated to reply outside your normal working hours **