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: Tue, 02 Jun 2020 01:27:15 +0000

Hi all,

How should we proceed with this? Also, a question about this option:

> 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

On Mon May 25 13:56:23 2020, [email-masked] wrote:
> Martin Björklund <[email-masked]> writes:
> 
> > Hi,
> >
> > "Amanda Baber via RT" <[email-masked]> wrote:
> >> 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?
> >
> > 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.
> >
> 
> 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

---

From: Martin Björklund <[email-masked]>
Date: Tue, 02 Jun 2020 08:17:01 +0200 (CEST)

Hi,

"Amanda Baber via RT" <[email-masked]> wrote:
> 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?

Personally, I think that it would be ok to add the "draft-version" to
the registry, but not to the YANG module.  The registry indicates that
there is a "pending" registration for the new value.  Then when the
RFC is published, the registry's reference is modified to point to the
RFC, and the YANG module is updated.

Perhaps Rob can help with a recommendation?

/martin

> _______________________________________________
> yang-doctors mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yang-doctors

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 4 Jun 2020 13:23:04 +0000

Hi Amanda, Martin,

Sorry, I was on PTO last week, and this email slipped through the cracks.

My suggestion is to do a combination of options (2) and (3) that Martin previously put forward.  I.e., I recommend:

The default position is that IANA should be to only update the YANG module when the RFC is published.  We end up with a single revision statement, and the YANG module only actually changes when it becomes an RFC.

However, I would also be okay, if document authors specifically requested from IANA that an earlier version of the YANG module be published before it gets through the RFC editor queue, e.g., if they knew the document is going to be stuck in MISREF for a while.  In this scenario you would end up with the two revision statements, one to indicate when the enums were updated, and a second update to indicate when the references were updated to the published RFC number.

Sound okay?

Thanks,
Rob

-----Original Message-----
From: yang-doctors <[email-masked]> On Behalf Of Martin Björklund
Sent: 02 June 2020 07:17
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [yang-doctors] [IANA #1170915] Protocol Action: 'Dissemination of Flow Specification Rules' to Proposed Standard (draft-ietf-idr-rfc5575bis-25.txt)

Hi,

/martin

---

From: "Amanda Baber via RT" <[email-masked]>
Date: Tue, 09 Jun 2020 00:25:58 +0000

Hi Rob, Martin, all,

If nobody objects, this works for us.

Does the fact that this document will be modifying two existing YANG entries to match the to-be-updated registry, rather than adding new entries, mean that we should make the change now rather than wait for publication? See the second paragraph of Section 11.1 for details:

https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-25#section-11.1

thanks,
Amanda

On Thu Jun 04 13:23:50 2020, [email-masked] wrote:
> My suggestion is to do a combination of options (2) and (3) that
> Martin previously put forward.  I.e., I recommend:
> 
> The default position is that IANA should be to only update the YANG
> module when the RFC is published.  We end up with a single revision
> statement, and the YANG module only actually changes when it becomes
> an RFC.
> 
> However, I would also be okay, if document authors specifically
> requested from IANA that an earlier version of the YANG module be
> published before it gets through the RFC editor queue, e.g., if they
> knew the document is going to be stuck in MISREF for a while.  In this
> scenario you would end up with the two revision statements, one to
> indicate when the enums were updated, and a second update to indicate
> when the references were updated to the published RFC number.
> 
> Sound okay?
> 
> Thanks,
> Rob
> 
> 
> Subject: Re: [yang-doctors] [IANA #1170915] Protocol Action:
> 'Dissemination of Flow Specification Rules' to Proposed Standard
> (draft-ietf-idr-rfc5575bis-25.txt)
> 
> Hi,
>

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Fri, 12 Jun 2020 08:34:29 +0000

Hi Amanda,

Ideally, I think that we would try and update both the registry and the YANG module derived from that at the same time.  Is that feasible?

Alvaro, please shout if you have a different opinion.

Thanks,
Rob

> From: yang-doctors <[email-masked]> On Behalf Of Amanda
> Baber via RT
> Sent: 09 June 2020 01:26
> Subject: [yang-doctors] [IANA #1170915] Protocol Action: 'Dissemination of
> Flow Specification Rules' to Proposed Standard (draft-ietf-idr-rfc5575bis-
> 25.txt)
> 
> Hi Rob, Martin, all,
> 
> Does the fact that this document will be modifying two existing YANG
> entries to match the to-be-updated registry, rather than adding new
> entries, mean that we should make the change now rather than wait for
> publication? See the second paragraph of Section 11.1 for details:
>

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 12 Jun 2020 03:51:30 -0700

I’m honestly ok with anything.   Updating at the same time makes sense to
me.

Thanks!

Alvaro.

On June 12, 2020 at 4:34:33 AM, Rob Wilton (rwilton) ([email-masked])
wrote:

Hi Amanda,

Ideally, I think that we would try and update both the registry and the
YANG module derived from that at the same time. Is that feasible?

Thanks,
Rob

---

From: "Amanda Baber via RT" <[email-masked]>
Date: Tue, 16 Jun 2020 18:50:38 +0000

Hi,

This works for us. In the future, if an IESG-approved I-D is making changes to a registry that's associated with an IANA-maintained YANG module, like SAFI Values or ifTypes, we'll hold off on making/modifying the assignment until we receive an RFC number. 

thanks,
Amanda