Subject: [yang-doctors] [IANA #1170915] Protocol Action: 'Dissemination of Flow Specification Rules' to Proposed Standard (draft-ietf-idr-rfc5575bis-25.txt)

From: "Amanda Baber via RT" <[email-masked]>
Date: Thu, 21 May 2020 19:01:14 +0000

Hi Alvaro, Rob, YANG Doctors:

We have a question about updating IANA-maintained YANG modules.

Newly-approved document draft-ietf-idr-rfc5575bis is making changes to an IANA-maintained YANG module. We understand that when we update the module, we need to include a reference to this document in the revision statement. 

Our normal workflow is to make registry updates with the I-D listed as the reference immediately after the IESG approves the document, then update those references after the RFC Editor assigns an RFC number. Can we update the reference in a revision statement without adding an additional revision statement?

thanks,

Amanda Baber
Lead IANA Services Specialist

---

From: Martin Björklund <[email-masked]>
Date: Sun, 24 May 2020 10:34:44 +0200 (CEST)

Hi,

"Amanda Baber via RT" <[email-masked]> wrote:
> Newly-approved document draft-ietf-idr-rfc5575bis is making changes to
> an IANA-maintained YANG module. We understand that when we update the
> module, we need to include a reference to this document in the
> revision statement.
> 
> Our normal workflow is to make registry updates with the I-D listed as
> the reference immediately after the IESG approves the document, then
> update those references after the RFC Editor assigns an RFC
> number. Can we update the reference in a revision statement without
> adding an additional revision statement?

Before discussing the question, it seems to me that you would run into
this problem for all new enums, if you follow the procedure above;

  1.  A draft that defines a new entry in "Subsequent Address Family
      Identifiers (SAFI) Parameters" is approved.

  2.  You update the registry with a reference to the approved draft.

  3.  You add a new enum to the YANG module, following the process
      defined in section 5.1 of RFC 8294.  Note that this section
      says that the enum will have a "reference" statement that
      replicates the reference in the registry.  So in this case, the
      reference would be a reference to the draft.

      You add a new revision statement to the YANG module.

  4.  The RFC is published, and you update the reference in the
      registry, and in the YANG module.

In step 4, you have the same (or at least similar) problem as you
describe above; a "reference" statement in the module is updated.

(An observation is that despite the fact that RFC 8294 mandates that
the "reference" statetment is used in the YANG modules, the initial
versions of these YANG modules, defined in the same RFC (8294), don't
include the reference statements!)

I can think of three possible ways to handle this situation:

  1.  When the RFC is published, simply update the reference statement
      in place, w/o any other changes.

  2.  When the RFC is published, update the reference statement in the
      enum, and add a new revision statement to the module.  (this
      means that a set of new enums from a doc results in two new
      revision statements).

  3.  Do not update the YANG module until the RFC is published.

(1) is a violation of YANG rules.  (2) and (3) would both be fine from
a YANG perspective.

Now, back to the original question.  It is an interesting special
case where you want to update the reference statement in a revision
statement.  RFC 7950 allows changes to "reference" statements, but it
requires a new revision statement, so it would look like:

  first:

    revision 2020-04-01 {
      description
        "Non-backwards-compatible change of SAFI names";
      reference
        "draft-ietf-...";
    }

  then:

    revision 2020-07-01 {
      description
        "Updated reference to RFC 7907.";
    }

    revision 2020-04-01 {
      description
        "Non-backwards-compatible change of SAFI names";
      reference
        "RFC 7907";
    }

This looks a bit weird, but is probably ok.

If you chose solution (3) above, the problem would obviously not
arise.

It would be good to hear other people's opinion.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 25 May 2020 15:38:35 +0200

> It would be good to hear other people's opinion.

What causes this and other problems is the fact that the registry and YANG module are maintained as relatively separate entities that have to be synchronized manually.

With the approach that we introduced in

https://tools.ietf.org/html/draft-ietf-dnsop-iana-class-type-yang-01

it is in principle possible that the traditional registry become the only authoritative source of the data:

- IANA would maintain only the registry and needn't care about the YANG module

- an RFC that defines the registry -> YANG mapping would specify a *procedure* (XSLT stylesheet) rather than a snapshot of the YANG module

- whoever needs the YANG module may apply the procedure at any time and get the *then current* revision of the registry data in YANG

- if the registry -> YANG mapping ever needs to be changed, the old RFC can be obsoleted and a new procedure specified, again without involving IANA.

The only missing piece is actually the module revision's description and reference (the revision date is taken from the registry's 'last updated' date), but perhaps it is not so critical because this info isn't present in the registry itself.

Lada

-- 
Ladislav Lhotka 
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: "Amanda Baber via RT" <[email-masked]>
Date: Mon, 25 May 2020 17:46:12 +0000

Hi all,

>   3.  Do not update the YANG module until the RFC is published.

If we were to do this, would we need to also wait to update the SAFI/ifType/et al. registry until the RFC is published?

thanks,
Amanda